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ABSTRACT 


Network-Centric  Warfare  (NCW)  is  a  theory  of  war  in  the  information  age  that 
hypothesizes  that  forces,  which  exploit  networked  conditions  better  than  their 
adversaries,  will  achieve  tactical  advantage.  Understanding  how  Network-Centric 
Systems  (NCS)  that  support  NCW  are  acquired  is  essential  for  the  continued 
development  and  delivery  of  systems  that  are  affordable,  meet  end-user  requirements, 
and  that  can  be  fielded  quickly. 

The  Network-Centric  Acquisition  Process  (NCAP)  will  enable  the  DoD  to  deliver 
NCS  that  are  quickly  fielded  and  that  leverage  the  use  of  leading-edge  technologies. 

The  NCAP  incorporates  the  systems  engineering  (SE)  approach  for  system 
design,  and  also,  maximizes  the  use  of  industry  “best  practices.”  The  envisioned  NCAP 
will  use,  among  other  things,  a  central  repository  of  design  information  (including 
software,  system  drawings,  etc.)  that  can  be  accessed,  or  pulled,  by  system  development 
teams,  and  modified  to  support  specific  system  needs.  The  NCAP  will  use  an  electronic 
business  (e-Biz)  marketplace  portal  where  developers  and  consumers  can  be  “matched- 
up”  in  order  to  share  their  products  or  make  needs  known,  and  where  NCS  evaluations 
are  available  for  review  by  interested  consumers. 

This  thesis  will  clarify  network-centric  systems  acquisition,  and  explore  the 
benefits  that  the  NCAP  would  provide. 
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EXECUTIVE  SUMMARY 


This  thesis  will  describe  the  current  acquisition  of  network-centric  systems, 
explore  the  benefits  that  a  network-centric  acquisition  process  would  provide,  and 
provide  recommendations  on  how  to  improve  the  acquisition  of  network-centric  systems. 
It  will  cover  a  wide  swath  of  information  relating  to  the  network-centric  world  and  will 
apply  it  to  a  very  narrow  part  of  network-centric  acquisition,  specifically  introducing  and 
explaining  a  proposed  Network-Centric  Acquisition  Process  (NCAP). 

N  etwor  k-C  entricity 

Network-Centric  Warfare  (NCW)  is  a  theory  of  war  in  the  information  age  that 
hypothesizes  that  forces  that  exploit  networked  conditions  better  than  their  adversaries 
will  achieve  tactical  advantage.  The  Department  of  Defense  (DoD)  has  been  undergoing 
a  transformation  in  the  way  it  develops  and  acquires  Network-Centric  Systems  (NCS) 
that  will  support  NCW.  Understanding  how  NCS  is  acquired  and  what  affects  NCS 
acquisition  is  essential  for  the  continued  development  and  delivery  of  systems  that  are 
affordable,  that  meet  user  requirements,  and  that  can  be  fielded  quickly. 

Department  of  Defense  Acquisition  and  the  Network-Centric  Acquisition  Process 

The  DoD  desires  to  field  NCS  that  leverage  the  use  of  “leading  edge” 
technologies  that  are  affordable  and  that  meet  the  warfighter’s  needs.  The  NCAP 
provides  a  framework  for  NCS  development  and  acquisition  that  ensures  that  these 
systems  use  the  most  up-to-date-technology.  The  framework  of  the  NCAP  consists  of 
several  acquisition  and  development  approaches  that,  when  integrated,  provide  for  quick 
fielding  of  NCS  with  the  benefit  of  frequent,  iterative  technology  upgrades. 

Network-Centric  Acquisition  Process  Framework 

NCAP  uses  a  Systems  Engineering  (SE)  approach  for  acquisition.  It  has  metrics 
for  evaluating  the  effectiveness  of  the  process.  NCAP  maximizes  the  reuse  of 
components  or  use  of  Off-The-Shelf  (OTS)  components  and  uses  a  data  repository  to 
facilitate  reuse  of  components.  In  addition,  NCAP  comprises  a  collaborative 
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development  environment,  that  stimulates  innovation  through  open  source  and  open 
license  requirements,  and  creates  an  electronic  business  marketplace  where  consumers 
and  developers  can  be  matched. 

The  NCAP  incorporates  best  practices  from  commercial  industry  in  order  to 
create  a  fast,  efficient  acquisition  process  that  focuses  on  delivering  “better”  speed  to 
“better”  capability. 

Thesis  Conclusions 

NCS  are  very  diverse  and  can  range  from  a  large  ship  to  a  small  unmanned  aerial 
vehicle,  but  the  common  thread  that  makes  them  network-centric  is  their  ability  to 
harness  the  power  of  the  network  to  gain  information  and  decision  superiority  over  an 
adversary.  What  allows  NCS  to  harness  the  power  of  the  network  is  the  backbone  of 
Information  Technology  (IT)  software.  The  proposed  NCAP  provides  an  efficient  and 
effective  way  to  acquire  the  IT  software  infrastructure,  or  network-centric  “glue”  that 
enables  network-centric ity. 

The  current  DoD  acquisition  system  is  slow,  serial  in  nature,  and  delivers  large 
“chunks”  of  capability  at  once.  The  system  is  expensive,  has  slow  refresh  cycles,  and 
virtually  ensures  that  processes  and  systems  are  stovepiped.  The  NCAP  provides  an 
alternative  for  faster  acquisition  by  focusing  on  delivering  “better”  speed-to-capability, 
while  incorporating  current  DoD  network-centric  guidance  and  industry  best  practices. 

The  NCAP  framework  incorporates  metrics  that  objectively  define  “better”  and 
measure  the  processes  ability  to  deliver  “better”  speed  and  “better”  capability.  The 
framework  also  incorporates  industry  best  practices  such  as  component  reuse, 
collaborative  environment,  open  architecture,  acquisition  data  repository,  electronic 
business  marketplace,  and  OTS  components. 

The  implementation  of  the  NCAP  will  require  changes  to  the  existing  DoD 
acquisition  processes,  including  in  the  way  Directives  (e.g.,  DoD  Directive  5000.01)  are 
interpreted. 
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Recommendations 


1.  Field  Test  the  Network-Centric  Acquisition  Process 

The  primary  recommendation  of  this  thesis  is  that  the  NCAP  should  be  adopted 
by  the  DoD  for  its  acquisition  of  network-centric  capabilities.  The  adoption  of  the  NCAP 
should  be  carried  out  in  a  small-scale,  acquisition  environment  or  prototype  venue,  and 
then  slowly,  and  iteratively,  scaled  to  larger  acquisitions. 

Use  NCAP  on  a  small  acquisition,  be  it  a  test  scenario,  and  then  expand  if 
successful  acquisitions  are  achieved. 

When  implementing  the  NCAP,  it  will  be  important  to  use  the  NCAP  metrics  that 
measure  “better”  speed-to-capability,  Anr  (net-ready  availability),  and  “better”  capability, 
Aiv  (information  value  availability)  as  a  means  to  objectively  evaluate  the  acquisition. 

Anr  measures  the  ratio  of  the  Initial  Estimated  Development  Time  (DTi)  over  the 
Capability  Development  Time  (CDT)  and  can  be  seen  in  Equation  (1). 

Equation  (1):  Anr=DT/CDT,  where  CDT=(DTe+  TTe  +CTe) 

Aiv  is  the  product  of  the  Information  Processing  Efficiency  (IPE)  and  the 
Delivered  Information  Value  (DIV)  and  can  be  seen  in  Equation  (2). 

Equation  (2):  Aiv=  IPE  x  DIV 

NCAP  framework  will  likely  not  be  immediately  fully  operational  (i.e.  data 
repository,  e-Biz  marketplace,  or  development  environment  working),  but  this  should  not 
slow  or  halt  the  implementation  of  the  NCAP.  As  NCAP  framework  items  become 
operational,  they  should  be  incorporated  into  the  operational  version  of  the  NCAP. 

2.  Change  the  Operation  of  the  Defense  Acquisition  System,  DoD  Directive 

5000.01 

DoD  should  implement  the  recommendations  of  the  Defense  Science  Board 
(DSB)  March  2009  report.  Department  of  Defense  Policies  and  Procedures  for  the 
Acquisition  of  Information  Technology. 
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By  implementing  the  DSB  reeommendations,  the  DoD  will  give  the  NCAP  an 
aequisition  framework  that  will  enable  fast,  iterative,  and  agile  aequisition. 

3,  Create  a  Network-Centric  Data  Repository 

The  DoD  should  begin  ereating  a  network-eentrie  data  repository  that  employs  the 
seareh  and  ontology  struetures  of  a  data  repository  as  deseribed  in  the  report:  Ontology- 
based  Solutions  for  Software  Reuse. 

The  ereation  of  the  data  repository  should  begin  slowly  and  on  a  small  seale,  and 
will  be  a  ehallenging  and  diffieult  task.  It  will  require  elear  and  well  thought-out 
guidanee  on  how  to  enter,  elassify,  and  store  repository  items.  The  network-eentrie  data 
repository  may  not  be  operational  until  several  iterations  of  the  NCAP  are  eomplete. 

4,  Framework  of  Network-Centric  Collaborative  Development  Environment 

DoD  should  conduct  further  studies  to  determine  the  best  framework  to  use  in  the 
network-centric  collaborative  development  environment.  The  framework  will  include  the 
development  environment  to  use,  the  standard  software  interfaces,  the  minimum  lA 
requirements,  and  the  licensing  rights  requirements. 

Forge.mil  should  serve  as  a  model,  prototype,  or  even  as  the  development 
environment  to  be  used  when  implementing  the  early  versions  of  the  NCAP. 

5,  Electronic  Business  Marketplace  Structure  and  Business  Rules 

DoD  should  conduct  further  studies  to  determine  the  best  framework  to  use  in  the 
electronic  business  (e-Biz)  marketplace.  Although  the  requirements  for  the  e-Biz 
marketplace  were  discussed  in  this  thesis,  consultation  and  collaboration  with  e-Biz 
marketplace  industry  leaders  (eBay  and  Amazon)  could  help  create  an  effective  DoD  e- 
Biz  marketplace,  or  prototype,  on  which  to  test  the  NCAP. 

6,  Network-Centric  Acquisition  Stakeholder  Education  and  Training 

DoD  should  use  the  material  in  this  thesis  to  create  a  course  that  would  help 
educate  DoD  acquisition  stakeholders  on  network-centricity,  the  DoD  acquisition 
process,  and  the  NCAP. 


ACKNOWLEDGMENTS 


This  thesis  would  not  have  been  eompleted  without  the  support  of  my  family. 
They  gave  me  the  time  and  inspiration  to  eomplete  this  thesis.  I  want  to  foremost 
aeknowledge  the  time  and  effort  put  in  by  my  personal  proofreading  team  (my  wife, 
Sandy;  Mother,  JoAnn  Vincent;  and  wordsmith-bb  Chuck  Ridgway). 

I  would  like  to  thank  and  recognize  my  thesis  advisor.  Dr.  Rachel  Goshorn,  whose 
vision  inspired  this  thesis.  She  provided  great  ideas,  knowledge,  support  and  motivation 
for  the  completion  of  this  thesis. 

Professors  Greg  Miller  and  Chris  Gunderson  provided  great  mentoring,  insight, 
and  knowledge  in  the  area  of  network-centric  warfare  and  acquisition.  Professor  Miller  is 
a  great  editor  who  really  helped  me  focus  on  the  important  points  of  the  thesis.  Professor 
Gunderson  shared  his  great  enthusiasm  for  network-centric  acquisition  and  inspired  me  to 
think  in  a  network-centric  way.  Professor  Gunderson  also  spent  many  mentoring 
sessions  helping  me  figure  out  the  “critical  path”  though  the  thesis. 

Writing  a  thesis  is  tough,  but  putting  the  final  finishing  touches  on  it  is  a 
bittersweet  way  to  complete  a  wonderful  learning  experience. 


XXV 


THIS  PAGE  INTENTIONALLY  LEET  BLANK 


XXVI 


I.  INTRODUCTION 


Network-Centric  Warfare  is  a  theory  of  war  in  the  information  age,  which 
hypothesizes  that  forces  that  exploit  networked  conditions  better  than  their  adversaries, 
will  achieve  tactical  advantage  [1].  The  Department  of  Defense  (DoD)  has  been 
attempting  to  transform  the  way  it  develops  and  acquires  network-centric  systems  (NCS) 
that  support  network-centric  warfare  (NCW).  Understanding  how  NCS  are  acquired  is 
essential  for  the  continued  development  and  delivery  of  systems  that  are  affordable,  meet 
end-user  requirements,  and  that  can  be  quickly  fielded. 

The  DoD  seeks  to  deliver  NCS  that  are  quickly  fielded,  and  that  leverage  the  use 
of  leading-edge  technologies.  The  proposed  network-centric  acquisition  process  (NCAP) 
is  an  enabler  for  fast,  efficient,  and  effective  NCS  development.  Using  the  NCAP,  NCS 
would  “ride”  the  technology  wave^,  have  fast  development  and  certification,  and  rely  on 
frequent,  iterative  technology  upgrades. 

The  NCAP  incorporates  the  Systems  Engineering  (SE)  approach  for  system 
design,  and  also  maximizes  the  use  of  industry  “best  practices”  such  as  maximizing  the 
reuse  of  software  and  subsystems.  The  envisioned  NCAP  will  use,  among  other  things,  a 
central  repository  of  design  information  (including  software,  system  architecture 
drawings,  etc.)  that  can  be  accessed,  or  pulled,  by  system  development  teams,  and 
modified  to  support  specific  system  needs.  The  NCAP  will  use  an  electronic  business  (e- 
Biz)  marketplace  portal  where  developers  and  consumers  can  be  “matched-up”  in  order 
to  share  their  products  or  make  needs  known,  and  where  NCS  evaluations  are  available 
for  review  by  interested  DoD  consumers. 

The  Defense  Acquisition  System  (DAS)  is  a  complex  system  that  receives  inputs 
from  many  organizations,  groups,  and  stakeholders  and  whose  output  is  controlled  by  the 


1  “Ride”  the  technology  wave  refers  to  NCS  taking  timely  advantage  of  technological  advances  in 
order  to  incorporate  them  into  the  design  and  deliver  advanced  technology  to  the  stakeholders.  This  helps 
ensure  that  new  fielded  technology  is  not  obsolete. 
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actions  of  other,  sometimes  very  different,  organizations,  groups,  or  stakeholders.  The 
DAS  goal  is  to  aequire,  field,  and  maintain  (life-eyele)  a  product,  or  system,  that  fulfills 
an  identified  eapability  need  [2], 

Developing  and  ehoosing  the  “best”  produet  is  often  a  daunting  task  beeause 
many  deeisions  must  be  made  to  determine  if  a  new  system  is  needed  or  if  an  existing 
system  meets  the  requirements,  or  if  modifieations  to  an  existing  system  will  be  required. 
The  deeision  “trade  spaee”  has  many  external  pressures  that  help  the  DAS  develop  the 
aequisition  deeision.  Ironieally,  these  pressures  tend  to  produee  ineffioieneies,  or  sub- 
optimization,  of  the  very  systems  being  developed  or  aequired. 

SE  has  been  an  integral  part  of  defense  aequisition  for  many  years.  The  use  of  SE 
proeesses  allows  for  the  development  of  systems  where  the  “end-user’s”  requirements  are 
effectively  elieited  and  efficiently  deeomposed  into  sub-systems  that  ean  easily  be 
integrated  into  a  valuable  and  useful  produet. 

A  thorough  understanding  of  how  the  DAS  operates,  and  the  impaet  of  the  use  of 
SE  proeesses,  will  benefit  all  aequisition  proeess  stakeholders.  The  way  DoD  aequires 
NCS  will  be  influeneed,  and  ehanged,  after  aequisition  stakeholders  realize  the  benefits 
that  the  NCAP  will  have  on  NCS  aequisition. 

This  thesis  will  explain  network-eentric  systems  aequisition,  network-eentric 
aequisition,  provide  metrics  to  describe  new  NCAP  models,  and  explore  the  benefits  that 
the  NCAP  would  provide. 

A,  BENEFITS  OF  THE  THESIS  STUDY 

The  thesis  study  benefits  the  DoD  aequisition  eommunity  beeause  it  will 
introduee  a  revolutionary  method  for  the  aequisition  of  network-eentrie  eapabilities  by 
the  DoD.  The  foundations  of  the  NCAP  ineorporate  industry  best  practiees,  SE 
prineiples,  and  are  a  paradigm  shift  toward  achieving  better  speed  to  better  eapability. 
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In  addition,  the  original  purpose  of  this  thesis  was  to  ereate  the  framework  for 
network-eentrie  systems  engineering  course  material  for  Naval  Postgraduate  School 
(NPS)  network-centric  SE  students.  Therefore,  along  with  assisting  the  DoD  acquisition 
community,  this  thesis  will  assist  in  network-centric  systems  engineering  education. 

B,  THESIS  OVERVIEW 

The  focus  of  this  thesis  is  a  process  by  which  the  DoD  can  begin  acquiring  NCS 
efficiently  and  cost  effectively,  specifically  the  NCAP. 

To  best  describe  the  NCAP,  it  is  crucial  to  understand  what  network-centricity 
entails  and  what  NCS  are.  Chapter  II  of  this  thesis  is  devoted  to  explaining  network- 
centricity.  It  describes  the  origins  of  NCW,  explains  the  theory  on  which  it  was  based, 
gives  current  DoD  instantiations  of  NCS,  and  finishes  by  defining  NCS. 

Chapter  III  gives  an  overview  of  Defense  Acquisition  by  giving  a  detailed 
explanation  of  the  Planning  Programming  Budgeting  and  Execution  System  (PPBES),  the 
Joint  Capabilities  Integration  and  Development  System  (JCIDS),  and  the  DAS. 

Chapter  IV  discusses  the  SE  approach  to  acquisition.  It  gives  an  overview  of  SE 
processes,  and  then  maps  a  generic  SE  approach  to  acquisition  to  the  DoD  acquisition 
process^. 

With  a  foundation  on  NCS,  DAS,  and  SE  (in  previous  chapters).  Chapter  V 
presents  the  NCAP.  It  gives  a  description  of  the  NCAP,  presents  metrics  to  measure 
network-centric  acquisition,  describes  the  framework  of  NCAP3,  and  discusses  a  new 
network-centric  acquisition  modeD. 

Chapter  VI  summarizes  Chapters  I-V  and  presents  conclusions  and 
rec  ommendations . 


2  The  DoD  acquisition  process  as  described  by  DoD  Directive  5000.01  [3]. 

3  The  NCAP  framework  includes  component  reuse,  collaborative  development  environment,  data 
repository,  electronic  business  marketplace,  use  of  off-the-shelf  components,  and  open  systems  and  open 
licensing  rights. 

^  This  is  an  acquisition  model  recommended  by  the  Defense  Science  Board  to  replace  the  model  used 
in  DoD  Directive  5000.01  [3]  and  discussed  in  Chapter  V. 
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II.  NETWORK-CENTRICITY 


A.  OVERVIEW 

This  chapter  will  lay  the  groundwork  for  the  thesis  by  describing  Network-Centric 
Operations  (NCO),  Network-Centrie  Warfare  (NCW),  Network-Centric  Systems  (NCS) 
and  by  discussing  the  origins  of  NCW.  NCW  is  a  driver  for  change  in  the  way  modern 
militaries  operate  and  by  understanding  NCW  it  is  easier  to  understand  the  purpose  of 
NCS. 

The  basic  premise  of  network-centrieity  stems  from  the  theory  that  when 
warfighting  forces  are  networked,  and  understand  how  to  exploit  the  “network  terrain,” 
they  ean  develop  an  informational  “tactical  advantage.”^  This  only  holds  true  when  the 
networked  information  and  data  flow  are  optimized  and  the  warfighters  do  not  suffer 
from  information  overload.  Situational  awareness  allows  for  Blue  Forces  to  achieve 
decision  superiority  and  dominant  maneuver ^  over  their  adversaries. 

In  this  chapter,  NCW’s  central  tenets  and  their  relevancy  in  the  transformation  of 
how  military  forces  operate  will  be  discussed.  Metcalfe’s  law  will  also  be  presented  to 
show  the  advantages  of  having  networked  forces,  followed  by  a  discussion  of  current 
network-centrieity  and  the  World  Wide  Web  (WWW). 

The  Global  Information  Grid’s  (GIG)  origins  will  be  discussed,  as  well  as  a  brief 
description  of  each  DoD  Department’s  complementary  instantiations  of  the  GIG,  and  the 
GIG’s  role  as  an  enabler  of  NCW. 

Finally,  this  chapter  will  examine  what  is  required  for  the  DoD  to  transform  into  a 
network-eentric  enterprise,  in  light  of  observations  that  have  emerged  sinee  the  DoD 
conceived  NCW. 


^  NCW  literature  has  evolved  to  reeognize  that  adversaries  will  eertainly  be  networked.  The  issue 
beeomes  taking  better  advantage  of  the  network  than  one’s  adversary  [4]  [5]. 

^  Decision  superiority,  dominant  maneuver,  and  the  central  tenets  of  NCW  will  be  discussed  later  in 
this  Chapter,  but  all  stem  from  the  writings  of  Cebrowski  and  Garstka  [6]. 
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B,  NETWORK-CENTRIC  WARFARE 

NCW  has  many  definitions,  but  the  first  definition  to  be  presented  was  originally 
diseussed  by  Viee  Admiral  Arthur  Cebrowski  and  John  Garstka  in  their  1998  artiele 
“Network-Centric  Warfare:  Its  Origins  and  Future”[7].  According  to  Cebrowski: 

[NCW]  and  all  of  its  associated  revolutions  in  military  affairs  grow  out  of 
and  draw  their  power  from  the  fundamental  changes  in  American  society. 

These  changes  have  been  dominated  by  the  co-evolution  of  economics, 
information  technology,  and  business  processes  and  organizations,  and 
they  are  linked  by  three  themes: 

•  The  shift  in  focus  from  the  platform  to  the  network 

•  The  shift  from  viewing  actors  as  independent  to  viewing  them  as  part  of  a 
continuously  adapting  ecosystem 

•  The  importance  of  making  strategic  choices  to  adapt  or  even  survive  in  such 
changing  ecosystems.  [6] 

In  Cebrowski ’s  definition,  he  talks  about  the  shift  from  “the  platform”  to  “the 
network,”  and  what  he  is  implying  is  the  shift  from  “platform-centric”  to  “network¬ 
centric”  operation.  Simply  stated,  this  means  that  when  a  single  platform,  or  multiple 
platforms  are  networked  together,  the  performance  of  the  combined  force  is  improved. 
This  is  achieved  because  networked  forces  have  access  to  more  information,  wider 
information  reach,  and  richer  information. 

According  to  John  Garstka, 

NCO  are  military  operations  that  are  enabled  by  the  networking  of  the 
force.  NCO  provide  a  force  with  access  to  a  new,  previously  unreachable 
region  of  the  information  domain.  The  ability  to  operate  in  this  region 
provides  warfighters  with  a  new  type  of  information  advantage,  an 
advantage  broadly  characterized  by  significantly  improved  capabilities  for 
sharing  and  accessing  information. 

NCW  enables  warfighters  to  leverage  this  information  advantage  to 
dramatically  increase  combat  power  through  self-synchronization  and 
other  network-centric  operations.  [8] 
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Self-synchronization  is  achieved  by  the  collectively  shared  situational  awareness 
and  refers  to  the  warfighter,  or  warfighting  unit’s  ability  to  continue  executing  their 
assigned  mission  even  if  the  top  layers  of  command  are  lost  or  disconnected  from  the 
network.  According  to  a  Naval  War  College  report, 

Self-synchronization  facilitates  speed  of  command,  the  process  by  which 
forces  use  information  superiority  to  lock-in  success  while  locking-out 
enemy  strategies  ...  In  summary,  self-synchronization  will  allow  forces, 
empowered  by  good  situational  awareness,  to  recognize  and  act  on  a 
situation  without  further  direction.  [9] 

The  central  tenets  of  NCW  are: 

•  a  robustly  networked  force  improves  information  sharing 

•  information  sharing  and  collaboration  enhances  the  quality  of  information  and 
shared  situational  awareness 

•  shared  situational  awareness  enables  collaboration  and  self-synchronization 
and  enhances  sustainability  and  speed  of  command 

•  the  above  ,  in  turn,  results  in  dramatically  increased  mission  effectiveness. 

The  central  hypothesis  of  NCW  is  that  a  force  with  these  capabilities  can  increase 

combat  power  by  better  synchronizing  effects  in  the  battlespace,  achieving  greater  speed 
of  command,  and  increasing  lethality,  survivability,  and  responsiveness  [10]. 

The  link  between  information  domain,  information  superiority,  decision 
superiority,  dominant  maneuver,  different  NCW  domains,  and  NCW  will  be  explained  in 
the  following  four  sub-sections. 

1.  Information  Domain  and  Information  Superiority 

Information  domain  is  the  domain  where  information  is  created,  manipulated,  and 
shared.  As  an  example,  military  Command  and  Control  (C2),  warfighter  coordination 
and  commander’s  military  intent  all  reside  in  the  information  domain  [8]. 

Information  superiority  is  a  condition  of  the  information  domain  that  is  achieved 
when  a  warfighter  has  an  information  advantage  over  an  adversary.  It  can,  therefore,  be 
stipulated  that  a  networked  force,  consisting  of  several  platforms,  will  have  informational 
superiority  over  a  non-networked  force.  Figure  1  shows  how  two  military  aircraft,  when 
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networked,  even  though  through  a  tactical  link^,  are  capable  of  achieving  informational 
superiority  over  a  non-networked  adversary  by  an  increase  in  information  “richness”  and 
“reach.”  This  information  superiority  allows  them  to  operate  in  the  “network-centric” 
region  of  the  information  domain,  as  opposed  to  the  “platform-centric”  region. 

According  to  a  DoD  report  to  Congress, 

[NCW]  allows  the  force  to  achieve  an  asymmetric  information  advantage. 

This  information  advantage  is  achieved,  to  a  large  extent,  by  allowing  the 
force  access  to  a  previously  unreachable  region  of  the  information  domain 
-  the  network-centric  region  -  that  is  broadly  characterized  by  both 
increased  information  richness  and  increased  information  reach.  [11] 


Reach 

Figure  1 .  Information  Domain  and  Effects  of  Networked  Forces  (From  [11]) 

NCW’s  advantage  is  built  upon  improved  capabilities  for  information  sharing  and 
networking  that  when  coupled  with  improved  sensing  capabilities  can  enable  a  force  to 
realize  dominance  over  its  adversary. 


^  These  aireraft  were  “networked”  via  a  taetieal  link.  Taetieal  links  are  serial  point-to-point 
eonneetions  governed  by  striet  eireuit  diseipline.  In  the  21st  eentury  the  term  “network”  usually  implies  a 
many-to-many  “eloud”  with  no  eireuit  diseipline  whatsoever. 
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2,  Decision  Superiority 

Informational  advantage  is  achieved  when  platforms  are  networked,  which  gives 
warfighting  commanders  a  competitive  advantage  over  their  adversaries.  Commanders 
and  their  forces  are  thus  able  to  make  better  decisions  that  can  be  implemented  faster  than 
the  adversary  can  react.  This  is  referred  to  as  “decision  superiority,”  and  it  provides 
significantly  enhanced  situational  awareness  to  not  only  the  commander,  but  to  the  entire 
force  [11]. 

Take  the  operational  example  of  an  air-to-air  mission  that  follows.  Advocates  of 
NCW  claim  that  network-enabled  information  sharing  provided  aircrews  with  enhanced 
situational  awareness  and  allowed  them  to  fight  smarter  and  make  better  decisions  faster 
and  therefore  win  more  decisively.  However,  there  are  some  caveats.  By  contrast, 
network-centric  theory  typically  considers  “networks”  to  be  many-to-many  networks 
with  unconstrained  data  flow.  Therefore,  while  this  example  clearly  illustrates  the  power 
of  decision  superiority,  it  is  not  clear  that  superiority  resulted  from  “network  enablemenf  ’ 
or  from  disciplined  information  exchange  and  command  and  control  (C2)  (preventing 
information  overload  enables  decision  superiority). 

An  operational  special  project  conducted  by  the  United  States  Air  Force  (USAF) 
in  the  1990s  demonstrated  how  pilots  flying  F-15Cs  equipped  with  tactical  data  links 
could  double  mission  effectiveness  (measured  in  kill  ratios).  Across  a  broad  spectrum  of 
engagement  scenarios,  day/night  and  ranging  from  one-on-one  to  eight  vs.  sixteen,  the 
combination  of  information  and  decision-making  advantages  resulted  in  a  2.6-fold 
increase  in  kill  ratios.  [11] 

3.  Dominant  Maneuver 

Dominant  maneuver  is  the  ability  of  networked  forces  to  gain  positional 
advantage  over  its  adversary  with  speed  and  a  high  operational  tempo  in  the  achievement 
of  assigned  military  tasks.  NCW  capabilities  can  support  dominant  maneuver  by 
enabling; 

•  Adaptive  and  concurrent  planning 

•  Coordination  of  dispersed  units 
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•  Status  updates  of  subordinate  units 

•  Roadmap  to  mission  accomplishment  [11] 

A  military  commander  who  can  achieve  dominant  maneuver  attains  a  positional 
advantage,  that,  when  combined  with  decisive  combat  power,  can  compel  his  adversary 
to  react  from  a  position  of  weakness — effectively  giving  control  of  the  battlespace  at  a 
time  of  the  commander’s  choosing. 

4,  Network-centric  Warfare  Domains 

Effective  NCW  requires  the  networking  of  the  three  domains  of  warfare.  Figure  2 
depicts  the  three  domains: 

•  Physical  domain 

•  Cognitive  domain 

•  Information  domain[  1 1  ] 

a.  Physical  Domain 

The  physical  domain  consists  of  the  place  where  military  influence  is 
desired.  This  domain  is  where  platforms  interact  and  where  networks  connect  them. 
Military  forces  strike,  maneuver,  and  protect  the  physical  domain. 

b.  Information  Domain 

As  defined  previously  in  paragraph  B.l,  the  information  domain  is  where 
information  resides.  It  is  created,  shared,  and  manipulated  by  its  users. 

c.  Cognitive  Domain 

This  domain  is  in  the  minds  of  the  warfighters.  The  cognitive  domain  is 
shaped  by  human  perception  and  nurtured  by  the  information  and  data  supplied  by  the 
information  domain.  It  is  the  most  difficult  to  predict  and  understand  and  therefore  is 
where  the  personal  experience  and  training  of  the  warfighters  can  either  lift  or  let  settle 
Sun  Tzu’s  “fog  of  war”[12].  Situational  understanding,  awareness,  and  assessment  are 
developed  in  the  cognitive  domain. 
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These  three  domains,  when  properly  networked,  ean  enable  NCW  to  oecur 
at  its  most  mature  form,  where: 

•  The  physical  domain  is  seamlessly  connected, 

•  The  information  domain  allows  for  efficient  collection,  sharing, 
and  access  to  information  allowing  the  warfighting  force  to 
achieve  informational  advantage  over  the  adversary,  and 

•  The  cognitive  domain  allows  for  shared  high  quality  of  situational 
awareness  and  the  ability  to  self-synchronize.  [11] 
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Figure  2.  Domains  of  Warfare  (From  [11]) 

Having  defined  the  different  aspects  of  NCW  (information  superiority, 
decision  superiority,  dominant  maneuver,  and  NCW  domains)  the  underlying  theory  of 
network-centricity  will  be  presented  in  the  next  section. 
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c. 


METCALFE’S  LAW 


NCW  advocates  the  use  of  Metcalfe’s  law  to  explain  the  claim  that  a  networked 
force  has  an  advantage  over  a  non-networked  force  because  of  the  potential  value  of  a 
network.  According  to  Metcalfe  (see  Figure  3),  as  the  number  of  nodes  in  a  network 
increases  linearly,  while  the  potential  “value”  or  “effectiveness”  of  the  network  increases 
quadratically^.  Figure  3  shows  how  “networked”  nodes  are  more  powerful  or  effective 
when  compared  to  the  linear  behavior  of  non-networked  nodes. 

Non-inear  relationship; 


NODES 

Figure  3.  Metcalfe’s  Law  (From  [13]) 

Figure  4  portrays  a  superior  information  position  relative  to  a  competitor  (or 
adversary)  in  military  operations.  The  three  dimensions  on  the  graph  are  percentage  of 
relevance,  accuracy,  and  timeliness.  As  100%  relevance,  accuracy  and  timeliness  is 
reached  in  each  axis,  the  upper  limit  of  the  information  domain  is  reached.  The  “Blue” 
and  “Red”  forces^  are  equivalent,  or  evenly  matched,  with  the  exception  that  the  “Blue” 
force  is  network-centric.  The  network  enables  information  intensive  interactions  between 
nodes,  giving  the  “Blue”  force  an  advantage  over  the  “Red”  force. 


^  For  every  “N”  node  in  a  network,  there  are  “N-l”  potential  interaetions  between  the  nodes.  In  a 
network  of  “N”  nodes,  the  total  number  of  potential  interaetions  is:  N*(N-1),  or  N^-N.  Thus,  for  large 
values  of  N,  the  NCW  theory  claims  that  the  “power”  or  “effectiveness”  is  proportional  to  [13]. 

^  “Blue”  and  “Red”  forces  are  respectively  synonymous  with  allies  and  adversaries. 
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In  the  twentieth  century,  network-centric  ideas  were  profound  because  they 
predicted  the  advances  that  networking  forces  would  provide.  In  the  twenty-first  century, 
they  have  become  self-evident.  Consider  the  network-centric  power  the  WWW  provides. 
Armed  with  a  search  engine,  anyone  with  the  ability  to  get  on  the  Internet  can  tap  billions 
of  data  sources  instantly  and  find  more  and  more  useful  information  than  someone  off 
line.  Indeed,  many  enterprises  from  the  world  of  e-commerce  (e.g.,  iPhone)  to  the  world 
of  e-Gov  (e.g.,  eFile  tax  return  services)  have  leveraged  network-centricity  to  their 
advantage.  With  respect  to  NCW,  clearly  if  Blue  Forces  were  “on-line”  and  Red  Forces 
were  not.  Blue  Forces  would  have  instant  information  superiority  because  of  the 
advantage  of  being  networked  with  a  larger  domain  of  nodes  i*’. 


%  Relevant  Information 


Timeliness 


%  Relevant  Information 


Red  Force  Capability 


Blue  Force  Capability 


Figure  4.  Superior  Information  Position  Vis-a-vis  an  Adversary  due  to  Network- 

Centricity  (From  [13]) 


Unfortunately  for  Blue  Force,  it  is  hard  to  imagine  an  adversary  that  does  not 
have  access  to  the  WWW.  On  the  contrary,  today’s  Red  Force  (e.g.  A1  Qaeda)  has  better 
access  to  “the  network,”  the  WWW,  than  U.S.  Blue  Forces  who  are  constrained  by  ultra- 
restrictive  security  policies  [14]  to  operate  on  private  military  networks  with  far  fewer 
nodes  than  the  WWW.  Clearly,  an  approach  that  compares  the  advantage  a  networked 


This  argument  assumes  that  the  information  that  the  Blue  Forees  want  is  available  on  the  WWW. 
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Blue  Force  has  over  a  non-networked  Red  Force  is  no  longer  relevant.  Likewise,  recent 
history  proves  that  any  relevant  approach  to  evaluating  the  effectiveness  of  NCW  must 
acknowledge  that  both  Blue  and  Red  Forces  may  not  be  traditional  military  actors. 

Twenty-first  century  experience  has  also  revealed  a  scale  issue  associated  with  the 
Metcalfe’s  Law  argument.  Access  to  billions  of  nodes  across  a  network  can  easily  lead  to 
information  overload,  or  in  other  words,  make  it  difficult  to  find  just  the  right  piece  of 
information  in  time  to  enable  a  critical  decision,  i.e.  achieve  information  superiority. 

Therefore,  in  today’s  environment,  adversaries  will  certainly  have  equal  or  better 
access  to  networks  of  data  providers  on  the  one  hand.  On  the  other  hand,  access  to  too 
much  unfiltered  information  is  counterproductive.  Hence,  Blue  Force  might  re-think  the 
original  NCW  premise  that  the  mere  availability  of  more  data  across  a  network  is 
equivalent  to  “value”  and/or  “effectiveness”  [15].  The  future  NCS,  of  multi-node 
networks,  will  require  automation  of  information  extraction  through  the  use  of  Artificial 
Intelligence  (AI)  systems.  It  is  through  the  automation  of  information  extraction,  that 
warfighters  can  gain  information  superiority  over  their  adversaries. 

D,  THE  GLOBAL  INFORMATION  GRID  AS  A  NETWORK-CENTRIC 
WARFARE  ENABLER 

Joint  Vision  2020  highlights  the  importance  of  achieving  improved  capabilities 
for  operating  in  the  information  domain,  and  the  DoD  solution  is  the  GIG.  According  to 
Joint  Vision  2020,  the  GIG  is: 

...the  globally  interconnected,  end  to  end  set  of  information  capabilities, 
associated  processes,  and  people  to  manage  and  provide  information  on 
demand  to  warfighters,  policy  makers,  and  support  personnel.  [16] 

DoD  intends  the  GIG  to  be  the  keystone  that  will  help  enable  both  NCW  and 
NCO  because  of  improved  information  sharing — ^better  information,  more  of  it,  and  faster 
sharing — amongst  all  stakeholders,  and  will  lead  to  improved  situational  awareness.  The 
GIG’s  success  will  depend  on  its  ability  to  achieve  fully  interoperable  and  interconnected 
forces,  a  daunting  task  that  is  made  ever  more  difficult  because  of  large  number  of  legacy 
systems  that  aren’t  able  to  be  interconnected. 


14 


The  GIG  hopes  to  enable  information  sharing  that  will  provide  eommanders  with 
improved  eapabilities  for  C2,  for  formulating  and  disseminating  eommander’s  intent 
based  on  up-to-date  situational  awareness,  and  enable  the  warfighting  force  to  be  more 
dispersed,  survivable,  agile  and  smaller. 

The  role  of  the  GIG  in  enabling  NCW,  Information  Superiority,  and  ultimately 
full  spectrum  dominance  is  portrayed  in  Figure  5.  The  vision  for  the  GIG  is  that  it  will 
dramatically  improve  information  sharing  capabilities  by  leveraging  cutting-edge 
information  technology  to  create  a  network-centric  information  environment. 
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Figure  5.  The  GIG  as  an  Enabler  (From  [11]) 

NCW  intends  to  revolutionize  the  way  we  conduct  warfare  and  the  GIG  is  the 
“transformation  initiative”  that  will  provide  the  infrastructure  required  to  network  the 
forces  [11].  In  the  final  analysis,  the  GIG  is  all  about  enabling  the  flow  of  information. 

The  next  four  sub-sections  will  discuss  the  origins  of  the  GIG,  and  how 
FORCEnet,  EandWarNet,  and  ConstellationNet  all  relate  to  the  GIG. 
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1,  Origins  of  the  Global  Information  Grid 

The  concept  of  a  “Global  Information  Grid”  was  borne  out  of  concerns  regarding 
interoperability  and  end-to-end  integration  of  Automated  Information  Systems  (AIS)ii. 
The  primary  function  of  the  GIG  is  to  support  and  enable  DoD  missions,  functions,  and 
operations  [18].  The  future  GIG  will  be  a  System-Of-Systems  (SoS)i2  that  provides  a  set 
of  value-added  functions  operating  in  a  global  context  to  support  processing,  storage,  and 
transport  of  information. 

The  current  version  of  the  GIG  is  not  fully  networked,  because  it  is  made  of  many 
smaller  networks  that  have  not  been  (and  may  not  be  able  to  be)  networked  together. 
Parts  of  the  GIG  have  many  stovepipe  systems,  with  varying  degrees  of  interoperability, 
and  whose  access  to  needed  information  is  constrained.  Through  a  series  of  capability 
increments.  Figure  6  shows  how  the  target  GIG’s  architectural  vision  will  be  achieved 
through  a  federated  1 3  approach  that  will  ensure  coherent  transition  to  the  target  GIG  [18]. 


Time-Phased  Measurable  and  Achievable  ‘'To-Be”  State  Target  GIG 


Today  2010  2012  2016 


Figure  6.  Transformation  to  “Target  GIG”  (From  [18]) 


2.  FORCEnet  and  the  GIG 

According  to  Rear  Admiral  Rodriguez,  the  Chief  Engineer  for  the  Space  and 
Naval  Warfare  Systems  Command  (SPAWAR)  from  2004  to  2008,  “FORCEnet  is  the 
Navy’s  instantiation  of  the  [DoD]  GIG”  [19].  Rodriguez  went  on  to  explain  that  if  the 


^  ^  AIS  refers  to  an  assembly  of  eomputer  hardware,  software,  firmware,  or  any  eombination  of  these, 
eonfigured  to  aeeomplish  speeifie  information-handling  operations  [17]. 

An  SoS  is  “a  set  or  arrangement  of  systems  that  results  when  independent  and  useful  systems  are 
integrated  into  a  larger  system  that  delivers  unique  eapabilities”  [2]. 

^3  Federated,  in  this  eontext,  refers  to  how  the  GIG  will  be  networked  and  viewed  as  a  whole  entity  by 
its  users,  and  viee  separate  intereonneeted  networks. 
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GIG  were  the  federal  highway  system,  whieh  eonnects  all  the  military  departments,  then 
FORCEnet  would  be  infrastructure  that  connects  that  Department  of  the  Navy’s  “roads” 
to  the  GIG.  The  users  of  the  transportation  system  (the  GIG)  would  use  the  same  signal 
and  signs  (common  architecture)  to  allow  for  interoperability. 

According  to  the  Naval  Network  Warfare  Command,  their  definition  of 
FORCEnet  is: 

The  operational  construct  and  architectural  framework  for  Naval  Warfare  in  the 
Information  Age,  to  integrate  WARRIORS,  sensors,  networks,  [C2],  platforms, 
and  weapons  into  a  networked,  distributed  combat  force,  scalable  across  the 
spectrum  of  conflict  from  seabed  to  space  and  sea  to  land...  The  future 
implementation  of  Network  Centric  Warfare  in  the  naval  services.  [20] 

3.  LandWarNet  and  the  GIG 

According  to  an  information  paper  published  with  the  2008  Army  Posture 
Statement,  [21]  “LandWarNet  is  the  Army’s  portion  of  the  GIG  [22].”  LandWarNet 
consists  of  infrastructure  and  services  that  move  information  through  the  Army’s 
network.  It  enables  the  “management  and  use  of  warfighting  and  business  information.” 
[22] 

LandWarNet  will  be  the  enabler,  in  conjunction  with  the  GIG,  for  the  Army’s 
achievement  of  decision  superiority  and  ultimately  full  spectrum  dominance.  It  will 
deliver  to  the  warfighter  voice,  data,  and  video  at  the  tip  of  the  tactical  edge,  with  the  goal 
extending  these  capabilities  to  the  lowest  levels  of  the  Army’s  modular  force  [22]. 

4,  C2  Constellation,  ConstellationNet  and  the  GIG 

C2  Constellation  is  the  Air  Force’s  solution  to  the  GIG  [23]  [24]  and  will  provide 
war  fighters  access  to  a  globally  distributed  common  knowledge  base  of  shared 
information,  providing  a  consistent  level  of  understanding  and  situational  awareness 
between  all  war  fighting  elements  [25].  ConstellationNet  is  the  communications 
network — air,  space,  and  terrestrial — that  will  allow  a  free  flow  of  information  that  is 
accessible  and  presented  to  warfighters  at  the  right  time  and  right  place  to  achieve  the 
commander’s  desired  effects. 
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E. 


THE  GLOBAL  INFORMATION  GRID  AND  FORCE  EXECUTION 


As  previously  stated,  the  GIG  hopes  to  be  the  foundation  with  which  NCW’s  full 
spectrum  dominance  can  be  achieved.  A  GIG  enabled  network-centric  force  can  utilize 
the  networks  and  its  processes  to  achieve  full  spectrum  dominance  as  forces  execute  their 
missions.  Figure  7  shows  how  the  GIG  connects  the  network-centric  forces,  facilitates 
the  acquisition  of  information  superiority  that  is  used  to  make  C2  decisions,  and  allows 
forces  to  be  utilized  with  the  goal  of  achieving  full  spectrum  dominance. 
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Figure  7.  Impact  of  the  GIG  on  NCW  (From  [11]) 


Information  sharing,  in  a  networked  environment,  enables  the  network-centric 
forces  to  gain  and  exploit  information — the  right  information,  to  the  right  people,  at  the 
right  time,  and  in  the  right  form.  Exploiting  information  correctly  gives  the  network- 
centric-forces  information  superiority,  a  situation  where  there  is  an  imbalance  in  their 
favor  in  the  information  domain.  With  information  superiority,  the  force  commander  can 
influence  his  C2  by  fusing  high  quality  shared  information  with  shared  awareness  and 
enabling  the  forces’  collaboration  and  synchronization.  This  culminates  in  the  ability  of 
the  forces  to  achieve  full  spectrum  dominance — a  competitive  advantage  across  the 
mission  spectrum — in  the  execution  of  their  tasking. 


18 


F.  NETWORK-CENTRIC  SYSTEMS  AND  NETWORK-CENTRIC 
SYSTEMS  ENGINEERING  CORE 

Network-Centric  Systems  (NCS)  support  the  concepts  presented  in  this  chapter. 
NCS  are  networked  systems  that  enable  warfighters  to  gain  decision  superiority  over  their 
adversaries — better  information,  faster,  and  thus  allowing  quicker  reaction. 

An  important  key  attribute  of  NCS  is  its  ability  to  deliver  valuable  information  to 
the  end-user.  Having  too  much  information  causes  information  overload,  so  network- 
centricity  advocates  the  delivery  of  Valued  Information  at  the  Right  Time  (VIRT). 
Professor  Rick  Hayes-Roth  defines  VIRT  as  follows: 

VIRT  is  a  generic  solution  to  the  problem  of  how  to  assure  that  important 
information  is  passed  along  and  unimportant  data  is  not.  The  technology 
can  be  implemented  across  diverse  deployment  platforms  to  meet  specific 
requirements.  In  its  most  simple  configuration  a  VIRT  appliance  consists 
of  an  intelligent  monitor  that  continually  examines  and  interprets  data 
sources  for  Condition  Of  Interest  (COI)  events  and  a  condition  alerter  that 
transmits  important  events  promptly  to  concerned  parties  using  their 
preferred  channels  and  styles.  [26] 

As  the  DoD  transitions  toward  network-centricity,  the  systems  and  SoS  that  are 
network-centric  will  collaborate  to  give  the  network-centric  users  the  informational 
superiority  that  will  lead  to  decision  superiority  and  ultimately  to  full  spectrum 
dominance  of  the  adversary.  During  the  network-centric  transition,  non-NCS  will  require 
upgrades  to  make  them  network  capable  and  allow  them  to  achieve  some  limited  form 
network-centricity. 

The  Network-Centric  Systems  Engineering  (NCSE)  core  is  presented  to  give  a 
background  on  NCS.  Eigure  8  is  the  NCSE  core  diagram.  The  NCSE  core  can  be 
thought  of  as  a  SoS  that  is  made  up  of  four  approaches  and  a  core  that  unites  the  four 
approaches  using  communication/networking  fundamentals  [27].  The  four  approaches  in 
the  NCSE  core  diagram  are: 

•  Top-down  approach  of  Net-Centric  Enterprise  Services  and  Service 
Oriented  Architectures  (including  Communities  Of  Interest  (COI), 
Collaboration,  Security,  Information  Assurance  (lA),  Discovery,  etc.) 
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•  Bottom-up  approach  of  smart  distributed  systems,  sueh  as  smart  sensor 
networks,  mobile  wireless  ad-hoe  networks,  sensor  fusion  and  artificial 
intelligence 

•  Middle  approach  of  smart  push(publish)/smart  pull(subscribe) 

•  Side  view  approach  of  a  disadvantaged  user  (communieations  to  the 
tactical  edge — whether  their  communications  are  limited  by  ehoice,  have 
limited  eommunications  capabilities,  and/or  laek  the  appropriate  seeurity 
levels  to  communieate,  but  overall  has  a  need  to  push/pull 
information/  services) 

These  four  approaches  are  integrated,  or  brought  together,  by  fundamentals  of 
networking,  eommunications,  distributed  eomputing,  and  real-time  processing.  Figure  8 
depicts  a  tree  with  four  branches  symbolizing  the  network-eentric  approaehes,  and  the 
trunk  symbolizing  the  integration  of  these  four  approaches  into  a  generic  NCS. 


Stove-pipes.  Different 
Terminology  A  Apppooche 


Smart  Push/Smart 
Pull 

[PufaJ«h/Subscribej 


Networks,  Comma!. 
Distributed  Computing. 
Real-Time  Processing, 
etc. 

NCSE  Core 


Figure  8.  Network  Centrie  Systems  Engineering  Core  (From  [27]) 

A  generic  NCS  has  all  four  branches  and  the  trunk  is  networked  together  in  such  a 
way  that  the  top-down  sub-system  is  able  to  share  stored  information  for  the  NCS  to 
operate.  In  addition,  this  generie  NCS  is  able  to  take  organic  data  and  use  the  bottom-up 
approach  to  share  it  with  other  NCS.  The  middle  approach  is  what  allows  the  top-down 
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and  bottom-up  approaches  to  effectively  pass  information  throughout  the  network  using 
smart  pull/push  and  AI.  The  trunk  of  the  NCSE  is  the  shared  “backbone”  on  whieh  the 
branehes  are  integrated. 

The  NCSE  eore  will  be  diseussed  again  in  Chapter  V,  when  it  is  used  to  depiet  a 
generie  view  of  the  NCAP. 

G.  CONCLUSION 

This  ehapter  diseussed  NCW,  its  origins,  and  how  the  DoD  has  shifted  to  embraee 
and  implement  the  network-eentric  environment. 

Also  diseussed  was  how  the  information  domain  is  changed  when  forees  are 
networked — network  eentrie  viee  platform  eentrie.  Networking  forees,  platforms,  or 
eapabilities  gives  warfighters  informational  and  deeisional  superiority,  whieh  enables 
them  to  maneuver  dominantly  over  an  adversary. 

With  regard  to  NCW,  the  three  domains  of  NCW  were  presented,  which  when 
properly  networked,  would  lead  to  a  mature  form  of  NCW  where  the  forees  are 
seamlessly  eonneeted  and  have  high  situational  awareness  and  the  ability  to  self- 
synchronize.  Metealfe’s  law  was  presented  to  explain  how  an  inerease  in  the  number  of 
network  nodes  impacts  force  effeetiveness. 

The  GIG  was  diseussed  regarding  how  it  will  be  the  foundation  on  whieh  NCW 
will  be  built,  with  the  goal  of  aehieving  full  speetrum  dominanee  in  the  battlefield  (aetual 
or  virtually).  Although  the  GIG  is  one  of  many  NCS,  it  is  the  model  through  whieh  all 
other  NCS  will  be  networked.  NCS  were  discussed  from  the  view  of  military  serviees 
and  a  NCSE  eore. 

The  reeent  DoD  transformation  has  been  based  upon  the  development  and/or 
aequisition  of  NCS  by  the  DoD,  with  the  focused  goal  of  enabling  the  network-eentrie 


Virtual  battlefield  refers  to  battles  waged  on  the  WWW  (eyber-warfare  or  dispersed  eommand  and 
eontrol  engagements. 
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fighter  in  NCW  and  NCO.  President  Bush  alluded  to  his  eommitment  to  network-eentric 
transformation  during  his  remarks  at  the  U.S.  Naval  Aeademy  Commencement  on  May 
25,  2001,  when  he  stated: 

We  must  build  forces  that  draw  upon  the  revolutionary  advances  in  the 
technology  of  war  that  will  allow  us  to  keep  the  peace  by  redefining  war 
on  our  terms.  I’m  committed  to  building  a  future  force  that  is  defined  less 
by  size  and  more  by  mobility  and  swiftness,  one  that  is  easier  to  deploy 
and  sustain,  one  that  relies  more  heavily  on  stealth,  precision  weaponry 
and  information  technologies.  [11] 

Although,  President  Bush’s  remarks  do  not  specifically  say  “network-centric,”  the 
context  of  the  speech  implied  that  NCS  will  allow  forces  to  be  smaller,  quicker,  and  self- 
synchronous. 

In  NCW,  the  goal  is  to  create  a  network-centric  force  that  can  share  and  exchange 
information  amongst  geographically  separated  units  of  the  warfighting  force,  regardless 
of  platform,  service,  command  structure,  or  location.  As  Garstka  stated,  “a  network¬ 
centric  force  is  an  interoperable  force,  a  force  that  has  global  access  to  assured 
information,  whenever  and  wherever  needed”  [8]. 

Given  the  minimal  progress  of  the  DoD  toward  its  network-centric  goals  over  the 
last  decade,  it  is  perhaps  time  to  re-evaluate  the  network-centric  transformation 
approachi^. 

After  an  overview  of  network-centricity  presented  in  this  Chapter,  Chapter  III  will 
give  an  overview  of  DoD  acquisition,  detailing  the  PPBES,  the  JCIDS,  and  the  DAS. 
Chapter  IV  will  present  SE  approach  and  explain  how  the  SE  approach  can  be  mapped 
into  the  DAS.  Network-centricity  is  the  foundation  for  the  acquisition  process  to  be 
discussed  in  Chapter  V. 

The  discussions  in  this  chapter  and  Chapters  III  and  IV  will  give  the  reader  the 
required  foundation  to  discuss  network-centric  as  an  acquisition  process. 


Network-centric  transformation  approach  includes  the  DoD  efforts  to  become  network-centric  and 
includes  all  the  efforts  it  has  taken  to  do  so. 
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III.  DEPARTMENT  OF  DEFENSE  ACQUISITION  OVERVIEW 


A.  OVERVIEW 

In  order  to  understand  network-eentrie  acquisition,  a  background  in  DoD 
acquisition  is  needed.  This  chapter  will  explain  how  the  DoD  acquisition  system 
operates.  System  acquisition  is  a  complex  and  iterative  process  that  takes  a  long  time  to 
complete  and  requires  the  interaction  of  many  dispersed  stakeholders.  The  DoD 
acquisition  system,  also  called  Big  “A”  acquisition  process  in  Figure  9,  is  comprised  of 
the  following; 

•  Planning  Programming  Budgeting  and  Execution  System  (PPBES); 

•  The  Joint  Capabilities  Integration  and  Development  System  (JCIDS); 

•  The  DoD  5000.2  Acquisition  Process,  also  know  as  the  Eittle  “a” 
acquisition  process. 

The  interaction  between  these  three  processes  is  fraught  with  tensions  that 
create  inefficiencies  in  the  acquisition  of  DoD  systems.  This  chapter  will  present  the 
different  stakeholders  of  the  DoD  acquisition  process  and  explain  how  they  directly 
impact  the  acquisition  process  [2]. 

Together,  the  three  parts  of  the  DoD  acquisition  system  provide  an  integrated 
approach  to  strategic  planning,  identification  of  needs  for  military  capabilities,  systems 
acquisition,  and  program  and  budget  development  [2]. 

B,  DEPARTMENT  OF  DEFENSE  ACQUISITION 

Acquisition  of  programs/systems  the  DoD  needs  in  order  to  conduct  its  missions 
is  extremely  complex  and  requires  the  earful  balance  of  many  diverging  views,  interests, 
needs,  and  directives. 


The  tensions  between  the  processes  range  from  budgetary  (Congressional  budget  process, 
acquisition  cost  overruns),  to  determining  what  the  warfighter  needs  (capability  gaps  determination). 
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At  a  high  level,  Figure  9,  shows  the  three  overlapping  proeesses  that  make  up  the 
DoD’s  aequisition  system.  These  proeesses  were  intended  to  work  together  to  help 
aequire  the  “best”  system/product  for  the  DoD,  but  in  reality,  effeetive  eoordination  and 
interaction  between  the  processes  is  necessary  for  successful  acquisition  to  occur. 


PLANNING, 

PROGRAMMING, 

BUDGETING 


ACQUISITION 

REQUIREMENTS^  PROCESS 

\ 


THE  ACQUISITION  SYSTEM 


Figure  9.  Two  views  of  the  DoD  Acquisition  System  (From  [28], [29]) 

In  Figure  9,  the  interaction  of  these  processes  is  where  competing  interests  are 
amplified,  which  introduce  inefficiencies  into  the  entire  “Big  A”  acquisition  process. 

A  successful  acquisition  is  described  as  a  system  or  service  whose  acquisition 
provides  the  needed  capabilities,  at  the  estimated  cost  (or  with  acceptable  cost  growth), 
and  that  is  delivered  in  a  timely  manner. 

The  next  few  sub-sections  will  discuss  the  PPBES,  the  JCIDS,  the  DoD  5000 
acquisition  process,  and  the  operation  of  the  Defense  Acquisition  System  (DAS). 

1,  Planning,  Programming,  Budgeting,  and  Execution  System 

The  Planning,  Programming,  Budgeting,  and  Execution  System  (PPBES)  is  one 
of  the  three  decision  support  processes  for  DoD  acquisition.  It  is  the  process  by  which 
the  DoD  allocates  resources  according  to  its  priorities  and  how  its  budgets  are  created. 
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In  the  Planning,  Programming,  Budgeting,  and  Execution  (PPBE)  process,  the 
Secretary  of  Defense  (SECDEE)  establishes  policies,  strategy,  and  prioritized  goals  for 
the  DoD,  which  are  subsequently  used  to  guide  resource  allocation  decisions  that  balance 
the  DoD  guidance  with  Presidential  or  Congressional  fiscal  constraints  [2], 

PPBE  is  based  on  assessments  of  the  world  environment  that  come  from  either  the 
Quadrennial  Defense  Review  (QDR)  or  the  National  Security  Strategy  (NSS).  A  strategy 
is  then  developed  that  takes  into  account  current  and  future  threats,  political  stances, 
economic  situation,  technological  advances,  and  resources.  Programs,  consisting  of 
hardware,  human  skills,  and  capabilities  are  defined  in  the  strategy.  A  budget  is  then 
created  to  fund  the  approved  programs,  which  then  is  executed  and  reviewed  to  ensure 
that  the  intended  strategy  was  achieved  [30]. 

The  PPBES  is  iterative;  and  in  theory,  it  is  supposed  to  be  bienniaE^,  but  it  results 
in  an  annual  budget  cycle.  The  biennial  budgets  are  supposed  to  support  the 
programming  guidance  of  the  PPBE,  but  due  to  the  constrained  budgets  and 
unplanned/urgent  requirements,  also  called  “fact-of-life  changes,”  they  are  not  able  to 
fully  support  this  guidance. 

The  next  sub-section  discusses  the  history  of  PPBES,  each  phase  of  the  PPBES, 
and  the  biennial  PPBES  cycles. 

a.  PPBES  History 

Robert  McNamara,  the  8**^  Secretary  of  Defense,  first  introduced  the 
PPBSi^  as  way  to  systematically  analyze  defense  requirements  and  produce  a  long-term, 
program-oriented  DoD  budget  [31]. 

In  1986,  Congress  authorized  biennial  budgeting  in  which  the  President 
submitted  a  two-year  budget  to  Congress.  Congress  would  then  appropriate  on  a  yearly 
basis  the  President’s  budget. 


Biennial  budgets  are  submitted  every  two  years. 

At  first,  it  was  called  the  Planning  Programming  and  Budgeting  System  (PPBS)  and  later  was 
changed  to  PPBES. 
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b.  Planning  Phase 

The  planning  phase  establishes  the  strategie  priorities  and  eapabilities 
required  to  aehieve  the  overarehing  DoD  strategy.  It  is  a  eollaborative  effort  by  the 
Offiee  of  the  Seeretary  of  Defense  (OSD)  and  the  DoD  Joint  Staff  This  phase 
determines  the  military  eapabilities  that  are  required,  ineluding  the  force  and  support 
level  objectives  to  accomplish  the  mission.  Deliverables  from  this  phase  are:  Joint 
Strategic  Review;  National  Military  Strategy;  OSD  Planning;  and  the  Strategic/Joint 
Planning  Guidance. 

The  planning  phase  begins  with  clearly  articulated  and  resource-balanced 
national  defense  policies  and  military  strategy,  also  known  as  the  Strategic  Planning 
Guidance  (SPG).  The  Joint  Programming  Guidance  (JPG)  evolves  from  the  SPG,  and  is 
the  link  between  planning  and  programming.  The  JPG  provides  guidance  to  the  DoD 
Departments  for  the  development  of  their  program  proposal.  [2] 

c.  Programming 

The  programming  phase  applies  resources  and  funds  to  programs  that 
meet  the  capabilities  required  to  achieve  the  strategic  priorities.  Resources  are  allocated 
to  support  the  goals  of  the  SPG  and  JPG.  This  phase  is  fiscally  constrained,  and  thus  the 
DoD  is  required  to  prioritize  desired  programs  as  it  in  translates  the  planning  guidance 
into  an  allocation  of  forces,  manpower,  and  dollars. 

The  programming  phase  begins  with  the  development  of  a  Program 
Objective  Memorandum  (POM),  by  each  DoD  Departments^.  The  programming  phase 
seeks  to  construct  a  set  of  programs,  within  fiscal  constraints,  that  respond  to  the 
guidance  and  priorities  of  the  JPG. 

The  POM  provides  a  comprehensive  description  of  the  proposed 
programs,  including  a  time -phased  allocation  of  resources — forces,  funding,  and 


SSS  The  DoD  is  made  up  of  three  Departments  (Departments  of  the  Army,  Navy,  and  Air  Force)  and  the 
Defense  Logistics  Agency.  [32]. 
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manpower — by  program,  projected  six  years  into  the  future.  DoD  Departments  can 
describe  important  programs  that  are  not  fully  funded  (or  not  funded  at  all)  in  the  POM, 
including  a  risk  assessment  of  what  a  funding  shortfall  would  cause. 

Senior  DoD  officials  and  the  Joint  Staff  review  each  department’s  POM  in 
order  to  integrate  them  into  a  coherent  and  overarching  set  of  DoD  programs.  During 
these  reviews  they  can  raise  issues  with  selected  portions  of  any  department’s  POM,  or 
any  funding  shortfalls  in  the  POM,  and  propose  alternatives  with  adjustments  to 
resources.  The  SECDEF  has  the  final  vote  concerning  issues  not  resolved  at  lower  levels, 
and  the  resulting  decisions  are  documented  in  the  Program  Decision  Memorandum 
(PDM)  [2]. 


d.  Budgeting 

The  budgeting  phase  properly  prices  the  programs,  develops  justifications 
and  a  budget  execution  plan.  This  occurs  concurrently  with  the  programming  phase, 
because  each  branch  of  service  submits  a  proposed  budget  estimate  together  with  a  POM. 

The  budget  converts  the  POM’s  programmatic  view  into  the  appropriation 
structure  used  by  Congressional,  that  will  include  budget  justification  documents.  The 
office  of  the  Under  Secretary  of  Defense,  Comptroller,  USD(C)  and  the  Office  of 
Management  and  Budget  (0MB)  review  each  department’s  budget  estimates.  This 
review  ensures  that  programs  are  funded  in  accordance  with  current  financial  policies,  are 
properly  and  reasonably  priced,  and  that  the  budget  documentation  is  adequate  to  justify 
the  programs  when  presented  to  the  Congress. 

Congressional  budget  analysts  provide  the  DoD  Departments  with  written 
questions  in  preparation  for  formal  hearings  where  the  analysts  review  and  discuss  the 
budget  in  detail.  After  the  hearings,  each  analyst  prepares  a  decision  document  (known 
as  a  Program  Budget  Decision,  or  PBD)  for  the  programs  and/or  appropriations  under  his 
or  her  area  of  responsibility.  The  PBD  proposes  financial  adjustments  to  address  any 
issues  or  problems  identified  during  the  budget  hearing.  The  PBDs  are  forwarded  to  the 
Deputy  Secretary  of  Defense  for  decisions  and  these  decisions  are  then  reflected  in  an 
updated  budget  submission  provided  to  the  0MB. 


27 


Once  each  DoD  Component’s  budget  is  integrated  into  the  DoD  budget,  it 
is  appended  as  a  part  of  the  President’s  Budget  request  to  the  Congress  [2],  Congress 
must  then  authorize  and  appropriate  funds  for  the  DoD  part  of  the  President’s  Budget. 
The  authorization  and  appropriations  bills  are  then  sent  to  the  President  for  signature  into 
law. 


e.  Execution 

The  execution  phase  performs  the  approved  plan — appropriated  funds  are 
spent  on  authorized  programs.  Metrics  are  developed  and  the  budget  execution 
performance  is  assessed  to  compare  actual  output  versus  planned  performance  for 
defense  programs.  Resources  are  adjusted  in  order  to  achieve  performance  goals  [33] 
[34].  If  existing  program  performance  goals  of  a  program  are  not  being  met,  the 
execution  review  may  lead  to  recommendations  to  adjust  resources  and/or  restructure 
programs  to  achieve  desired  performance  goals.  [2] 

Execution  review  occurs  simultaneously  with  the  program  and  budget 
reviews.  This  is  done  to  provide  feedback  concerning  the  effectiveness  of  past  and 
current  resource  allocations. 

f.  PPBE  Biennial  Cycles 

In  2003,  the  DoD  adjusted  the  PPBE,  formally  known  as  the  Planning, 
Programming,  and  Budgeting  (PPB)  process,  to  support  a  two-year  cycle  that  results  in 
biennial  budgets. 

Management  Initiative  Decision  (MID)  913,  dated  May  22,  2003, 
described  this  process.  The  changes  were  made  because  the  DoD’s  process  for  strategic 
planning,  system  development  and  acquisition,  and  program  and  budget  development 
were  not  properly  integrated.  Although  the  planning  and  programming  phases  imposed 
fiscal  discipline,  they  failed  to  integrate  strategic  decisions  into  a  coherent  defense 
program  [35].  The  rationale  behind  MID  913  was  to  allow  the  DoD  to  improve  on 
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budget  efforts  (planning  and  execution).  By  formulating  two-year  budgets,  the  DoD 
could  use  the  “off-year”  (odd  numbered  year)  to  focus  on  budget  execution  and  program 
performance  [36]. 
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MID  913  supported  submission  of  a  biennial  DoD  budget  that  is  part  of 
the  President’s  Budget  request  to  Congress  for  even-numbered  Fiseal  Years  (FY) .  In  the 
biennial  budget  eycle,  even-numbered  years  are  ealled  “on-years,”  while  odd-numbered 
years  are  ealled  “off-years.”  Figure  10  displays  a  nominal  timeline  for  the  PPBE  phases 
in  an  “on-year”  and  “off-year.” 

Sinee  Congress  provides  yearly  appropriations  to  the  DoD,  the  biennial 
budget  is  in  theory  submitted  on  an  “on-year”  and  an  amended  budget  justifieation  is 
submitted  for  the  “off-year,”  with  faet-of-life  ehanges  to  the  budget. 

In  the  “off-year”  the  DoD  departments  will  not  provide  revised  POMs  or 
budget  estimates,  but  will  provide  Program  Change  Proposals  (PCPs)  and/or  Budget 
Change  Proposals  (BCPs)  to  aecount  for  fact-of-life  changes.  PCPs  and  BCPs  address 
only  single  issues  and  identify  resource  reductions  that  will  offset  any  program  or  budget 
cost  growth. 

The  PPBES  process  takes  about  three  years  to  complete.  As  stated  earlier, 
all  the  cycles  overlap  and  thus  in  June  2009  (see  red  vertical  line  in  Eigure  11)  the  DoD  is 
executing  EY09,  enacting  EYIO,  and  programming  EY 1 1 . 
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Resource  Allocation  Process  -  Overlap 
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Figure  11.  PPBE  System  Overlap  (From  [33]) 

2,  Joint  Capabilities  Integration  and  Development  System 

The  Joint  Capabilities  Integration  and  Development  System  (JCIDS)  is  the  seeond 
of  the  three  decision  support  processes  for  DoD  acquisition.  It  is  governed  by  the 
Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  Instruction  3 170. OIF,  and  CJCS  Manual 
3170.01C.  The  Defense  Acquisition  Guide  (DAG)  calls  JCIDS  “a  joint-concepts-centric 
capabilities  identification  process  that  allows  joint  forces  to  meet  future  military 
challenges.” 

The  primary  objective  of  the  JCIDS  process  is  to  ensure  that  the  end-user  receives 
the  capabilities  required  to  successfully  execute  the  assigned  missions.  JCIDS  is  a  series 
of  top-down  analyses,  derived  from  strategic-level  guidance,  that  identifies  capability 
gaps^o  and  a  potential  solution  by  assessing  existing  and  proposed  capabilities  in  contrast 
to  their  contribution  to  future  joint  concepts,  in  the  context  of  integrated  architectures  of 

Capability  gaps  are  analyses  that  take  warfighter  requirements  and  determine  if  an  existing  system 
ean  meet  that  requirement,  or  if  a  new  solution  is  required  [37]. 
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multiple  interoperable  systems.  The  JCIDS  proeess  supports  DoD  aequisition  by 
providing  validated  eapabilities  and  assoeiated  performanee  eriteria  to  be  used  as  a  basis 
for  aequiring  the  right  weapon  systems  and  by  providing  the  PPBES  with  prioritization 
and  affordability  adviee  [37].  The  eapability  gaps  are  addressed  by  a  eombination  of 
materiel  and/or  non-materiel  solutions^!.  The  reeommended  materiel  solutions,  onee 
approved,  lead  to  aequisition  programs. 

JCIDS  eneourages  eollaboration  between  end-users  (the  warfighters)  and  system 
developers  (the  providers)  early  in  the  proeess.  This  improves  the  ability  of  many  DoD 
organizations  to  influenee  what  the  proposed  solutions  will  be  to  the  eapability  gaps. 

a.  JCIDS  Origins  and  the  Joint  Requirements  Oversight  Council 

The  JCIDS  proeess  was  ereated  to  support  the  Joint  Requirements 
Oversight  CouneiTs  (JROC)  strategie  requirements  to  validate  and  prioritize  joint 
warfighting  requirements. 

The  JROC’s  mission  is  to  assist  the  CJCS  in  identifying  and  assessing  the 
priority  of  joint  military  eapabilities  (ineluding  existing  systems  and  equipment)  to  meet 
the  national  military  and  defense  strategies  and  in  eonsidering  alternatives  to  any 
aequisition  program  by  evaluating  the  eost,  sehedule,  and  performanee  eriteria.  In 
addition,  it  ensures  that  the  assignment  of  eapability  priorities  eonforms  to  and  refleets 
projeeted  DoD  resouree  levels,  as  stated  in  the  JPG.  [38] 

The  JROC  reviews  programs  designated  as  JROC  interest  and  supports  the 
aequisition  review  proeess  in  aeeordanee  with  U.S.  Code  [38].  The  JROC  reviews  and 
validates  all  JCIDS  doeuments  for  Aequisition  Category  (ACAT)  I  and  lA  programs  (see 
Table  1)  and  other  programs  that  are  designated  as  high-interest.  For  ACAT  ID  and  I  AM 
programs,  the  JROC  reviews  and  makes  reeommendations  to  the  Defense  Aequisition 
Board  (DAB)  or  Information  Teehnology  Aequisition  Board  (ITAB). 


21  Non-materiel  solutions  would  be  ehanges  to  doetrine,  organization,  training,  materiel,  leadership 
and  edueation,  personnel,  and  faeilities — also  known  as  DOTMLPLF. 
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Acquisition 

Category 

(ACAT) 

Reason  for  ACAT  Designation 

ACAT  1 

*  Major  Defense  Acquisition  Program  (MDAP)  with  dollar  value:  more  than  $365  million 
in  fiscal  year  (FY)  2000  constant  dollars 

*  For  procurement,  of  more  than  $2,190  billion  in  FY  2000  constant  dollars 

*  Milestone  Decision  Authority  (MDA)  designation  as  special  interest 

ACAT  lA 

*  Major  Automated  Information  System  (MAIS):  A  DoD  acquisition  program  for  an 
Automated  Information  System  (AIS)  (either  as  a  product  or  a  service)  that  is  either: 

a)  Designated  by  the  MDA  as  a  MAIS;  or 

b)  Estimated  to  exceed:  $32  million  in  FY  2000  constant  dollars  for  all  expenditures, 
incurred  in  any  single  fiscal  year;  or 

*  $126  million  in  FY  2000  constant  dollars  for  all  expenditures,  directly  related  to  the  AIS 
definition,  design,  development,  and  deployment,  and  incurred  from  the  beginning  of  the 
Materiel  Solution  Analysis  Phase  through  deployment  at  all  sites; 

*  $378  million  in  FY  2000  constant  dollars  for  all  expenditures,  directly  related  to  the  AIS 
definition,  design,  development,  deployment,  operations  and  maintenance,  and  incurred 
from  the  beginning  of  the  Materiel  Solution  Analysis  Phase  through  sustainment  for  the 
estimated  useful  life  of  the  system. 

*  MDA  designation  as  special  interest 

ACAT  II 

*  Does  not  meet  criteria  for  ACAT  I 

*  Major  system 

a)  Dollar  value:  estimated  to  require  an  eventual  total  expenditure  for  RDT&E  of  more 
than  $140  million  in  FY  2000  constant  dollars 

b)  For  procurement  of  more  than  $660  million  in  FY  2000  constant  dollars 

ACAT  III 

*  Does  not  meet  criteria  for  ACAT  II  or  above 

*  AIS  that  is  not  a  MAIS 

Table  1.  Summary  of  Acquisition  Categories  (From  [39]) 


The  JROC  is  chaired  by  the  Vice  CJCS,  by  delegation  from  the  CJCS  [40] 
who  also  serves  as  the  co-chair  of  the  DAB.  The  other  JROC  members  are  the  Vice 
Chiefs  of  each  military  service  [41], 

b.  JCIDS  Process 

The  JCIDS  process  evaluates  existing  and  proposed  capabilities  in  light  of 
their  contribution  to  future  joint  concepts.  JCIDS  is  supported  by  robust  analytic 
processes  and  identifies  capability  gaps  and  potential  solutions.  While  JCIDS  considers 
the  full  range  of  Doctrine,  Organization,  Training,  Materiel,  Leadership  and  Education, 
Personnel  and  Facilities  (DOTMLPF)  solutions,  the  focus  remains  on  the  pursuit  of 
"materiel"  solutions  [2]. 
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Figure  12.  JCIDS  interaction  with  Defense  Acquisition  (From  [2]) 


The  JCIDS  process  is  initiated  through  the  execution  of  a  Capabilities- 
Based  Assessment  (CBA).  The  CBA  is  based  on  high-level  military  doctrine,  such  as  the 
Joint  Operating  Concept  (JOC)  and  the  Joint  Integrating  Concept  (JIC).  The  CBA 
carefully  evaluates  the  required  capabilities,  compares  them  to  the  shortfalls  in  weapon 
systems  and  the  inherent  operational  risk,  and  develops  a  potential  solution  for  the 
capability  shortfall. 

The  results  of  the  CBA  are  documented  in  a  Joint  Capabilities  Document 
(JCD),  or  Initial  Capabilities  Document  (ICD),  that  validate  the  need  for  a  certain 
capability,  and  describe  a  potentially  affordable  and  technically  feasible  solution  [37].  As 
the  CBA  is  refined  in  an  iterative  process,  the  ICD  will  be  incorporated  into  the 
Capabilities  Development  Document  (CDD),  which,  in  turn,  will  be  incorporated  into  the 
Capability  Production  Document  (CPD).  Figure  12  shows  how  the  JCIDS  process 
interacts  with  different  phases  of  DoD  acquisition. 
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3,  The  Defense  Acquisition  System — Little  “a”  Acquisition  Process 

The  third  part  of  the  support  proeess  for  DoD  aequisition  is  the  Defense 
Acquisition  System  (DAS).  DoD  Instruction  5000.02  and  DoD  Directive  5000.01  govern 
the  DAS,  and  it  is  commonly  known  as  the  little  “a”  acquisition  process  shown  in  Figure 
9.  These  instructions  lay  the  framework  of  how  the  DoD  will  acquire  systems  that  are 
effective,  affordable,  and  delivered  in  a  timely  manner.  The  DAS  is  the  management 
process  by  which  the  DoD  acquires  weapon  systems  and  automated  information  systems. 

The  DAS  framework  provides  an  event-based  process,  where  acquisition 
programs  proceed  through  a  series  of  milestones  associated  with  significant  program 
phases.  It  also  identifies  specific  statutory  and  regulatory  reports  and  other  information 
requirements  for  each  milestone  and  decision  point.  A  key  principle  of  defense 
acquisition  is  the  use  of  ACAT  (see  Table  1),  where  programs  with  increasing  dollar 
value  and  management  interest  are  subject  to  more  stringent  oversight. 

Major  Defense  Acquisition  Program  (MDAP)  and  Major  Automated  Information 
Systems  (MAIS)  are  the  most  expensive  acquisition  systems  and  information  systems 
programs,  as  shown  in  Table  1.  Most  MDAP  and  MAIS  are  subject  to  review  by  senior 
DoD  officials,  these  are  normally  ACAT  1  or  ACAT  lA.  ACAT  ID  programs  are 
subject  to  review  by  the  Under  Secretary  of  Defense  for  Acquisition,  Technology,  and 
Logistics,  USD(AT&L).  ACAT  1AM  programs  are  MAISs  that  are  reviewed  by  the 
Assistant  Secretary  of  Defense  for  Networks  and  Information  Integration/  DoD  Chief 
Information  Officer  (ASN(NII)/DoD  CIO). 

These  individuals  are  the  Milestone  Decision  Authority  (MDA)  for  their 
respective  programs.  The  MDA  reviews  programs  and  decides  if  programs  will  continue 
to  move  past  milestone  points  [39]. 

4,  Operation  of  the  Defense  Acquisition  System 

Figure  13  depicts  the  Defense  Acquisition  System  (DAS).  The  DAS  has  five 

phases:  Materiel  Solution  Analysis  (MSA);  Technology  Development  (TD);  Engineering 

and  Manufacturing  Development  (EMD);  Product  and  Deployment  (PD);  and  Operations 

and  Support  (OS).  Entrance  into  the  Defense  Acquisition  Management  Systems  (DAMS) 
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requires  a  Material  Development  Decision  (MDD).  Each  phase  has  specific  entrance  and 
exit  criteria,  which  are  specified  at  the  MDD  or  Milestone  A,  B,  or  C  reviews  or  once 
production  has  completed. 
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entry  into  any  phase  of  the  acquisition 
management  system 

•  Entrance  criteria  met  before  entering  phase 

•  Evolutionary  Acquisition  or  Single  Step  to 
Full  Capability 


^ 


(Program 

initiation) 


IOC 


FOC 


Materiel 

Solution 

Analysis 

Technology 

Development 

Engineering  and 
Manufacturing 
Development 

Production  & 
Deployment 

Operations  & 
Support 

V  Materiel 

>  Development 

✓  Decision 

/\Post-  ^\Post- 
V  pdra\/cdr  A 

LRIP/IOT&E  Decision 

>/  Review 

Pre-Systems  Acquisitiony\ 


Tv 


Systems  Acquisition 


Sustainment 


Decision  Point  /\=  Miiestone  Review  >=  Decision  Point  if  PDR  is  not  conducted  before  Milestone  B 

Figure  13.  The  Department  of  Defense  Acquisition  System  (From  [39]) 


a.  Materiel  Development  Decision 

A  MDD  is  required  regardless  of  what  phase  of  the  acquisition  process  the 
program  intends  to  enter.  The  MDD  is  the  formal  entry  point  into  the  acquisition  process 
and  is  a  mandatory  step  that  ensures  entry  phase  decisions  are  based  on  approved 
requirements  and  on  a  rigorous  assessment  of  alternatives.  The  JCIDS  process  overlaps 
into  the  DAS  at  the  MDD,  where  a  materiel  decision  is  made. 

The  DoD  plans  a  MDD  review,  with  the  MDA,  when  a  need  for  a  materiel 
solution  is  shown.  The  MDA  examines  the  ICD  and  then  can  approve  the  guidance  from 
the  Analysis  Of  Alternatives  (AoA).  The  AoA  is  a  study  intended  to  aid  decision  making 
by  illuminating  the  risk,  uncertainty,  and  the  relative  advantages  and  disadvantages  of 
alternatives  being  considered,  to  satisfy  a  mission  need  [42]. 

Once  the  MDD  is  complete,  the  MDA  determines  acquisition  phase  of 
entry  (see  Figure  14)  and  documents  its  decision  in  an  Acquisition  Decision 
Memorandum  (ADM)  [39], [43]. 
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Figure  14.  Materiel  Development  Decision  and  Acquisition  Entry  Phase  (From  [43]) 

b.  Materiel  Solution  Analysis  Phase 

The  purpose  of  this  DAS  phase  is  to  assess  potential  materiel  solutions  and 
to  satisfy  the  entrance  criteria  for  the  Technology  Development  Phase. 

The  MSA  phase  begins  with  an  approved  ICD  that  has  a  preliminary 
concept  of  operations,  a  description  of  the  needed  capabilities,  and  the  program  risk. 
Although  an  ADM  was  signed  for  the  MDD,  this  does  not  mean  that  a  program  has  been 
initiated22.  In  the  MSA  phase,  the  DoD  component  begins  to  assess  preliminary  materiel 
solutions,  identify  key  technologies,  and  estimate  life-cycle  cost.  This  phase  culminates 
once  the  specific  exit  criteria  of  the  phase  have  been  attained  and  a  materiel  solution  is 
approved  at  the  Milestone  A  review  [39], [43].  The  purpose  of  the  MSA  phase  is  to 
develop  materiel  solution  options  for  the  identified  capability  need. 

c.  Technology  Development  Phase 

The  focus  of  the  TD  phase  is  to  reduce  technology  risk,  determine  and 
mature  the  appropriate  set  of  technologies  to  be  integrated  into  a  full  system,  and  to 
demonstrate  critical  technology  elements  in  a  prototype. 


Program  initiation  normally  occurs  after  the  Milestone  B  review. 
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TD  is  a  process  of  continuous  technology  discovery  and  development  that 
requires  close  eollaboration  between  the  Seienee  and  Teehnology  (S&T)  eommunity,  the 
end-user,  and  the  system  developer.  It  is  an  iterative  proeess  designed  to  assess  the 
viability  of  teehnologies  while  simultaneously  refining  end-user  requirements.  If 
teehnology  is  found  not  to  be  mature,  the  DoD  eomponent  ean  use  alternative  teehnology 
that  is  mature  and  that  ean  meet  the  end-user’s  needs  or  engage  the  user  in  a  dialogue  on 
appropriately  modifying  the  requirements. 

A  system  enters  this  phase  after  fulfilling  an  AoA,  with  an  approved 
materiel  solution  (done  at  the  Milestone  A  review),  and  after  being  fully  funded  for  the 
teehnology  development  phase.  This  phase  requires  eompetitive  prototyping  of  the 
system  or  key-system  elements  as  well  as  a  Preliminary  Design  Review  (PDR)  that  must 
be  eondueted  for  the  eandidate  designs.  A  PDR  report  is  provided  to  the  MDA  with 
reeommended  requirements  trade-offs  [43]. 

The  Teehnology  Development  Strategy  (TDS)  is  a  doeument  that  is 
drafted  during  the  MSA  phase,  and  finalized  during  the  TD  phase.  The  TDS  doeuments 
the  following:  preliminary  aequisition  strategy  (eosts  sehedule,  and  performanee  goals); 
speeific  eost  and  schedule;  and  performance  goals  for  the  teehnology  development  phase. 

This  phase  is  exited  when  an  affordable  program  or  inerement  of  military 
eapability  has  been  identified.  This  means  that  the  teehnology  and  manufaeturing 
proeesses  have  been  assessed,  demonstrated  in  the  applieable  environment, 
manufaeturing  risks  have  been  identified,  and  the  system  ean  be  developed  within  a  short 
period  of  time  [43]. 

A  Capabilities  Development  Doeument  (CDD)  will  be  prepared  to  support 
initiation  of  the  aequisition  program.  The  CDD  builds  on  the  ICD  and  provides  the 
detailed  operation  performanee  parameters  of  the  system.  Onee  a  program  passes  the 
Milestone  B,  the  TD  phase  is  eompleted  and  indicates  program  initiation. 

(1)  Preliminary  Design  Review.  The  Preliminary  Design  Review  (PDR) 
ean  oecur  before  or  after  Milestone  B  review,  but  that  depends  on  how  the  TDS  or  ICD 
are  written.  A  PDR  oeeurs  before  Milestone  B  when  this  satisfies  TD  phase  objeetives. 
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associated  prototyping  activity  and  the  approved  TDS,  and  if  the  Program  Manager 
(PM23)  desires.  The  PDR  should  be  conducted  at  the  system  level  and  include  end-user 
representatives  and  certification  stakeholders. 


PDR  planning  is  conducted  in  order  to  establish  the  program  baseline 
(hardware,  software,  and  human/support  systems),  underlying  architectures  and  to  define 
a  high-confidence  design.  All  system  elements  (hardware  and  software)  require  an 
adequate  level  of  maturity  for  a  successful  PDR. 

If  PDR  is  not  conducted  prior  to  program  initiation.  Milestone  B,  it  should 
be  done  soon  after  entrance  in  the  EMD  phase  (see  Figure  15). 

Following  PDR,  the  PM  submits  a  PDR  report  and  the  MDA  conducts  a 
formal  Post-PDR  Assessment.  The  PDR  report  reflects  any  requirements  trades  based 
upon  the  PM’s  assessment  of  cost,  schedule,  and  performance  risk  [43].  The  results  of 
the  MDA's  Post-PDR  Assessment  are  documented  in  an  ADM.  A  successful  PDR  will 
inform  requirements  trades;  improve  cost  estimation;  and  identify  remaining  design, 
integration,  and  manufacturing  risks. 

The  Milestone  B  decision  allows  the  MDA  to  determine  the  Fow-Rate 
Initial  Production  (FRIP)  quantities  for  MDAPs  and  major  systems  [3 9], [43]. 


33  The  PM  is  the  DoD  designee  that  supervises  the  development  or  aequisition  of  a  system. 
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Engineering  &  Manufacturing 
Development  -  Two  Major  Efforts 
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Figure  15.  Preliminary  Design  Review  (From  43]) 


d.  Engineering  and  Manufacturing  Development  Phase 

The  purpose  of  the  Engineering  and  Manufacturing  Development  (EMD) 
phase  is  to  develop  a  system  or  an  increment  of  capability;  complete  full  system 
integration;  develop  an  affordable  and  executable  manufacturing  process;  ensure 
operational  supportability  (minimizing  the  logistics  footprint);  implement  Human 
Systems  Integration  (HSI);  design  for  producibility;  ensure  affordability;  and  demonstrate 
system  integration,  interoperability,  safety,  and  utility  [39]. 

The  EMD  phase  is  guided  by  the  CDD,  acquisition  strategy.  Systems 
Engineering  Plan  (SEP),  and  Test  and  Evaluation  Master  Plan  (TEMP).  The  emphasis  of 
this  phase  is  SE  and  technical  reviews.  The  PM  may  provide  a  PDR  report,  if  not  done 
during  the  TD  phase  (see  Eigure  15)  and  must  provide  a  Critical  Design  Review  (CDR) 
report  to  the  MDA. 
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Figure  15  shows  that  the  EMD  phase  has  two  major  efforts:  Integrated 
System  Design;  and  System  Capability  and  Manufaeturing  Proeess  Demonstration.  The 
post-CDR  assessment,  eondueted  at  the  end  of  the  Integrated  System  Design  effort, 
allows  the  MDA  to  determine  if  the  results  of  the  CDR  warrant  eontinuing  the  phase  to 
Milestone  C. 

The  Integrated  System  Design  effort  is  intended  to  define  system  and  SoS 
funetionality  and  interfaces,  complete  hardware  and  software  detailed  design,  and  reduce 
system-level  risk.  The  program  can  enter  the  System  Capability  and  Manufacturing 
Process  Demonstration  effort  part  of  this  phase  upon  completion  of  the  Post-CDR 
Assessment  and  establishment  of  an  initial  product  baseline. 

The  System  Capability  and  Manufacturing  Process  Demonstration  effort  is 
intended  to  demonstrate  the  ability  of  the  system  to  operate  in  a  useful  way  consistent 
with  performance  requirements  and  that  the  manufacturing  processes  can  support  system 
production. 

This  effort  will  end  when  the  system  meets  approved  requirements  and  is 
demonstrated  in  its  intended  environment.  In  addition,  manufacturing  processes  have 
been  effectively  demonstrated,  industrial  capabilities  are  reasonably  available,  and  the 
system  meets  Milestone  C  entrance  requirements.  The  completion  of  this  phase  is 
dependent  on  a  decision  by  the  MDA  to  commit  to  the  program  at  Milestone  C  or  a 
decision  to  terminate  the  project  [3 9], [43]. 

e.  Production  and  Deployment  Phase 

The  purpose  of  the  Production  and  Deployment  (PD)  phase  is  to  achieve 
an  operational  capability  that  satisfies  mission  needs.  Operational  test  and  evaluation 
will  determine  the  effectiveness  and  suitability  of  the  system.  The  ADM  documents  the 
commitment  to  production  at  Milestone  C. 
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A  positive  Milestone  C  deeision  authorizes  entry  into  LRIP  (for  MDAPs 
and  major  systems),  into  produetion  or  procurement  (for  non-major  systems  that  do  not 
require  LRIP)  or  into  limited  deployment  in  support  of  operational  testing  for  MAIS 
programs  or  software-intensive  systems  with  no  production  components. 

Full  Rate  Production  (FRP)  decision  requires  demonstrated  control  of  the 
manufacturing  process  and  acceptable  reliability  in  process  control  data,  and  the 
demonstrated  control  and  capability  of  other  critical  processes.  The  beyond  LRIP 
decision  is  based  upon  the  MDA  FRP  decision  review,  and  documented  in  an  ADM  [39]. 

f  Operations  and  Support  Phase 

The  purpose  of  the  Operations  and  Support  (OS)  Phase  is  to  execute  a 
support  program  that  meets  materiel  readiness  and  operational  support  performance 
requirements,  and  sustains  the  system  in  the  most  cost-effective  manner  over  its  total  life- 
cycle.  OS  has  two  major  efforts,  Life-Cycle  Sustainment  and  Disposal  [39]. 

g.  Evolutionary  Acquisition  and  Recent  DoD  Acquisition  Changes 

Evolutionary  acquisition  is  the  preferred  DoD  strategy  for  rapid 
acquisition  of  mature  technology  for  the  end-user.  An  evolutionary  approach  delivers 
capability  in  increments,  recognizing  up  front  the  need  for  future  capability 
improvements.  It  requires  a  careful  balance  between  available  capability  and  resources, 
and  the  desire  to  put  that  capability  in  the  hands  of  the  user  quickly  [43]. 

Each  capability  increment  is  designed  to  give  additional  capabilities  to  the 
end-user.  When  evolutionary  strategy  is  used,  the  initial  delivered  capability  represents 
only  partial  fulfillment  of  the  overall  capability  described  in  the  ICD,  and  successive 
technology  development  efforts  continue  until  all  capabilities  have  been  achieved.  In  an 
evolutionary  acquisition,  the  identification  and  development  of  the  technologies 
necessary  for  follow-on  increments  to  continue,  in  parallel  with  the  acquisition  of 
preceding  increments,  allows  the  mature  technologies  to  more  rapidly  proceed  into  the 
EMD  Phase.  Each  increment  of  an  evolutionary  acquisition  program  will  include  a 
Milestone  A  and  will  have  an  MDA-approved  TDS  (see  Eigure  16)  [39]. 


42 


With  evolutionary  acquisition,  increments  of  capabilities  are  deployed  to 
the  end-user  in  a  time-phased  basis.  Figure  16  shows  the  development  flow  through  the 
DAS;  it  shows  how  there  can  be  parallel  capability  development  cycles  that  continually 
improve  the  capabilities  of  the  systems  being  developed  in  the  previous  development 
increment.  Specifically,  as  an  acquisition  transitions  from  MSA  phase,  through  MS  “A” 
review,  through  the  TD  phase  and  MS  “B”  review,  a  decision  is  made  by  the  Defense 
Acquisition  Board  (DAB24)  to  begin  the  next  increment  of  capability  for  the  systems. 


Continuous  Technology  Development  and  Maturation 

Figure  16.  Evolutionary  Acquisition  (From  [43]) 


Having  discussed  the  DoD  acquisition  system,  the  next  section  of  this  chapter  will 
discuss  how  SE  has  effected  the  way  systems  are  acquired  by  the  DoD. 

C.  SYSTEMS  ENGINEERING  IMPACT  ON  DEPARTMENT  OF  DEFENSE 
ACQUISITION 

DoD  Instruction  5000.02  specifies  that  SE  be  used  in  the  acquisition  life-cycle.  It 
claims  that  “rigorous  SE  discipline  is  necessary  to  ensure  that  [DoD]  meets  the 
challenges  of  developing  and  maintaining  needed  warfighting  capability.”  Eurthermore, 
it  requires  that  SE  be  “embedded  in  program  planning”  [39]. 


24  The  DAB  is  the  senior  advisory  board  for  defense  aequisitions  in  the  DoD.  The  board’s  make  up  is 
similar  to  the  make  up  of  the  JROC  and  ineludes  the  Viee  CJCS,  the  serviee  Seeretaries,  and  a  number  of 
Underseeretaries  of  Defense.  The  DAB  plays  an  important  role  in  the  DAS.  Members  of  this  board  are 
responsible  for  approving  the  Major  Defense  Aequisition  Programs  (MDAP)  [44]. 
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SE  provides  a  way  to  integrate  the  system  development  proeesses  that  will  define 
future  system  performance,  cost,  schedule,  and  risk.  As  systems  become  larger  and  more 
complex,  the  design,  development,  and  production  of  a  system,  or  SoS,  require  the 
integration  of  numerous  activities  and  processes.  The  DoD  has  recognized  the 
importance  of  using  the  SE  approach  in  achieving  an  integrated  and  balanced  system 
solution.  [2] 

There  are  many  beneficial  impacts  that  arise  from  the  use  of  SE  for  DoD 
acquisition.  They  begin  with  the  careful  elicitation  of  end-user  requirements  that  focus 
on  designing  the  right  system.  They  continue  through  the  diligent  integrated  product 
design  that  ensures  that  the  end  product  will  be  able  to  be  assembled  and  that  the  sub¬ 
systems  will  correctly  interface  with  each  other.  Most  importantly,  SE  allows  the  PM  to 
effectively  use  the  design  tradespace  to  mitigate  risks  (cost,  schedule,  performance)  in 
order  to  deliver  a  product  that  meets  the  end-user’s  need,  is  delivered  in  a  timely  manner, 
and  is  affordable.  SE  and  the  SE  process  will  be  further  discussed  in  Chapter  IV. 

D,  CONCLUSION 

This  chapter  has  discussed  how  the  DoD  acquisition  system  operates  and  will  be 
the  foundation  (DoD  acquisition)  for  discussing  the  need  for  the  NCAP.  The  three 
decision  support  processes  for  DoD  acquisition  were  briefly  presented  and  explained. 
There  are  many  nuanced  inter-relations  between  the  three  systems  where  a  small  change 
in  one  can  have  large  impact  in  one  of  the  others.  If  the  changes  are  large  enough,  it  can 
have  devastating  effects  for  DoD  acquisition  (e.g.,  Eittoral  Combat  Ship  (ECS)).  The 
interaction  between  these  three  processes  is  delicate  and  if  not  properly  handled  can 
create  inefficiencies  in  the  acquisition  of  DoD  systems. 

These  three  processes  provide  an  integrated  approach  to  strategic  planning, 
identification  of  needs  for  military  capabilities,  systems  acquisition,  and  program  and 
budget  development  that  ultimately  are  responsible  for  providing  the  warfighter  with  the 
right  capability,  at  the  right  time,  and  in  an  affordable  way. 

Chapter  IV  will  discuss  the  SE  approach  to  acquisition  by  explaining  the  SE 
processes. 
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IV.  SYSTEMS  ENGINEERING  APPROACH  TO  ACQUISITION 


A.  OVERVIEW 

The  role  of  SE  is  to  elicit  the  needs  of  the  customer's ;  identify  appropriate  system 
requirements;  develop  a  system  architecture  from  which  to  design  and  build  the 
applicable  Configuration  Items  (Cl);  and  integrate  the  Cl  to  produce  a  system,  or  SoS, 
which  meets  the  needs  of  the  customer. 

According  to  the  Systems  Engineering  Guide  for  Systems  of  Systems: 

An  SoS  is  defined  as  a  set  or  arrangement  of  systems  that  results  when 
independent  and  useful  systems  are  integrated  into  a  larger  system  that 
delivers  unique  capabilities.  Both  individual  systems  and  SoS  conform  to 
the  accepted  definition  of  a  system  in  that  each  consists  of  parts, 
relationships,  and  a  whole  that  is  greater  than  the  sum  of  the  parts; 
however,  although  an  SoS  is  a  system,  not  all  systems  are  SoS.  [45] 

SE  is  involved  in  each  phase  in  the  system  or  SoS’s  life-cycle.  The  SE  processes 
are  applied  early  in  the  materiel  solution  development  and  then  continuously  throughout 
the  total  system  life-cycle  [2].  The  best  system  solutions  are  achieved  by  applying 
established  SE  processes  continuously  to  the  planning,  development,  and  implementation 
of  a  system  or  SoS  acquisition. 

SE  is  typically  implemented  through  multi-disciplined  teams  of  subject  matter 
experts,  who  translate  user-defined  capabilities  into  operational  system  specifications 
consistent  with  cost,  schedule,  and  performance  constraints.  SE  uses  a  total  life-cycle 
view  that  encompasses  the  “cradle  to  grave”  planning.  Since  cost  to  implement  system 
changes  increases  as  a  product  moves  further  along  its  life-cycle,  the  SE  approach 
encourages  the  leverage  of  early  trade-offs  in  system  design.  Early  identification  and 
timely  mitigation  of  system  design,  schedule,  and  integration  issues  reduce  overall 
system  acquisition  cost.  The  Systems  Engineering  Plan  (SEP),  which  is  an  overarching 
development  strategy  for  the  system,  should  be  established  early  in  the  system 
development,  and  be  updated  as  the  program  matures  [2]. 

In  the  DoD  the  customer,  end-user,  or  warfighter  is  considered  the  generator  of  requirements 
because  they  are  the  ones  that  need  it. 
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This  chapter  will  present  a  small  sample  of  different  SE  proeesses,  define  a 
generic  SE  process  (events,  phases,  and  stakeholders),  and  then  deseribe  how  the  SE 
proeess  is  mapped/applied  to  the  DoD  aequisition  proeess. 

B  SYSTEMS  ENGINEERING  PROCESSES 

There  are  many  different  SE  approaehes  that  ean  be  used  in  the  DoD  aequisition 
proeess.  Chapter  4  of  the  Defense  Acquisition  Guide  {DAG)  refers  to  several  proeess 
standards  and  eapability  models  that  deseribe  best  praetiees  and  processes  for  eondueting 
systems  engineering  [46].  Some  of  the  proeess  models  presented  in  the  DAG  are: 

•  ISO/IEC  15288,  Systems  and  Software  Engineering- System  Eife-Cyele 
Proeesses 

•  ISO/IEC  12207,  Systems  and  Software  Engineering-Software  Eife-Cyele 
Proeesses 

•  ANSI/EIA  632,  Processes  for  Engineering  a  System. 

There  are  many  different  SE  proeess  standards,  but  they  all  share  a  eommon 
element — the  detailed  breakdown  of  system  requirements  in  order  to  design  and  ereate  a 
system  that  meets  the  eustomer’s  requirements.  The  following  sub-sections  will  present 
three  well  know  SE  proeess  models,  the  SE  “Vee,”  the  Waterfall,  and  the  Spiral. 

1,  Systems  Engineering  “Vee” 

The  SE  Vee,  Eigure  17,  is  a  graphieal  representation  of  the  system  development 
eyele.  The  main  steps  to  be  taken  for  produet  development  are  summarized.  The  left 
side  of  the  Vee  deeomposes  the  requirements  and  ereates  system  speeifieations — ealled 
the  project  definition.  The  bottom  and  right  side  of  the  Vee  show  the  build,  testing, 
integration,  and  verification  of  system  eomponents — ealled  the  project  build,  integration 
and  test. 
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Figure  17.  Systems  Engineering  “Vee”  (From  [47]) 

2,  Waterfall  Model 

Figure  18  shows  the  waterfall  model  and  is  more  applicable  to  software 
engineering  than  to  other  forms  of  engineering.  This  SE  model  is  a  sequential,  mostly 
software,  development  process  in  which  iteration  is  allowed  between  adjacent  phases. 
The  major  problem  with  the  waterfall  model  is  that  iteration  between  non-adjacent  phases 
occurs  too  frequently  (i.e.,  between  software  requirements  and  detailed  design)  [47]. 
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Figure  18.  Waterfall  Model  of  Software  Engineering  (From  [47]) 


rovi^w 


Figure  19.  Spiral  Model  (From  [47]) 
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3,  Spiral  Model 

Figure  19  shows  the  spiral  model.  It  is  primarily  a  software  development  process 
model  where  elements  of  design  and  prototyping  are  combined.  This  model  combines 
features  of  the  prototyping  and  waterfall  models.  Characteristic  of  this  model  is  the 
sequential  evolution  of  development  cycle  phases,  where  iteration  is  only  allowed 
between  adjacent  phases.  This  process  model  addressed  the  need  to  reduce  production 
time.  It  shortened  the  time  from  user  requirement  definition  to  the  delivery  of  a  useful 
product  [47]. 

4,  Defense  Acquisition  Guide’s  Systems  Engineering  Process 

Figure  20  shows  the  DAG's  SE  process  (rows  of  the  figure),  and  it  shows  how  the 
different  phases  of  the  SE  approach  (columns  of  the  figure),  used  by  the  DAG,  map  onto 
the  different  phases  of  the  DoD  acquisition  process.  Interestingly,  some  of  the  technical 
process  phases  occur  almost  concurrently26,  where  the  majority  of  the  level  of  effort,  or 
cost,  is  done  during  the  same  phase  of  the  acquisition  process. 
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(Erom  [46]) 


26  For  example,  Figure  20  shows  that  Stakeholder  Requirements  Definition,  Requirements  Analysis, 
and  Architecture  Design  processes  are  taking  place  during  the  MSA  and  TD  phases  of  the  DoD  acquisition 
process. 
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The  SE  process  described  in  the  DAG  is  similar  to  the  SE  “Vee”  described  in 
Figure  17.  The  DAG  SE  process  shows  a  direct  mapping  of  DAG  technical  processes  to 
the  DoD  acquisition  process  timeline  (discussed  in  Chapter  III). 

C.  MAPPING  THE  GENERIC  SYSTEMS  ENGINEERING  APPROACH  TO 
THE  DEPARTMENT  OF  DEFENSE  ACQUISITION  PROCESS 

In  order  to  map  the  DoD  acquisition  processes  to  the  various  SE  models,  a  generic 
SE  approach  is  used  (discussed  in  the  Appendix).  Figure  21  shows  how  the  generic  SE 
approach  and  types  of  people  that  typically  work  in  each  phase  (as  described  in  the 
Appendix)  would  be  mapped  to  the  DoD  acquisition  system,  discussed  in  Chapter  III,  and 
as  seen  in  Figure  13.  This  mapping  is  done  to  show  that  the  many  SE  approaches  can  be 
utilized  in  a  parallel  way  that  complements  the  DoD  Acquisition  System  framework. 
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Figure  21 .  Systems  Engineering  Process  Mapping  to  DoD  Acquisition  System  (From 
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1,  Materiel  Solution  Analysis  Phase 

In  the  early  phases  of  system  acquisition,  the  customer,  “X”27  type  person 
interacts  with  the  sales,  marketing,  and  acquisition  personnel,  the  “A”28  people,  to  begin 
the  system  design.  The  early  system  design  takes  into  consideration  the  technology 
opportunities,  schedule  and  funding  constraints,  and  system  performance  parameters  in 
order  to  correctly  express  the  Key  Performance  Parameters  (KPP)  of  the  system. 
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Figure  22. 


System  Engineering  Steps  During  Materiel  Solution  Analysis  Phase  (From 

[46]) 


27  From  the  Appendix,  “X”  people  are  the  “big  picture”  thinkers,  visionaries,  and  dreamers.  “X” 
people  take  the  end-user  needs,  analyze  them,  and  are  capable  of  correctly  describing  the  capability  gap — 
the  need — that  requires  a  materiel  solution.  Since  they  understand  the  “big  picture,”  they  do  not  concern 
themselves  with  the  intricate  details  of  the  systems  they  require. 

28  From  the  Appendix,  “A”  people  interact  constantly  with  the  customer,  “X”  types,  thus  “A”  people 
usually  have  marketing,  business,  and  detail  design  experience  .  “A”  people  need  to  be  able  to  effectively 
communicate  with  the  customer  to  correctly  elicit  the  system  requirements.  “A”  people  need  to  also 
interact  with  “B”  people,  to  make  sure  what  they  plan  is  technically  feasible,  and  therefore  “A”  people  with 
technical  backgrounds  (typically  were  a  “B”  person  previously)  are  more  successful. 
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Figure  22  shows  the  SE  proeess  steps  (using  the  SE  “Vee”)  conducted  during  the 
MSA  phase.  It  is  interesting  to  note  that  each  step  has  a  capabilities  “trades”  process  that 
is  iterative,  where  the  customer  and  system  developer  can  modify  the  design  in  order  to 
make  the  system  better  meet  the  customer’s  requirements. 

There  are  many  steps  taken  during  the  MSA  phase,  on  the  left  and  downward  side 
of  the  SE  “Vee.”  The  project  team  interprets  user’s  needs  (step  1),  develops  the  concept 
performance  (steps  2  &  3),  and  decomposes  the  concept  into  components  and  objectives 
(steps  4  &  5).  On  the  right  and  upward  side  of  the  SE  “Vee,”  the  system  design  is 
integrated  and  analysis  is  done  on  enabling  components,  overall  system  functionality, 
overall  system  performance  and  constraints,  and  fulfillment  of  defined  user  needs  (steps  6 
thru  9)[46]. 


a.  Materiel  Solution  Analysis  Technical  Reviews 

Technical  reviews  performed  during  the  MSA  phase  include  the  Initial 
Technical  Review  (ITR),  which  is  done  at  the  beginning  of  the  MSA  phase,  and  the 
Alternative  System  Review  (ASR),  which  is  done  at  the  end  of  the  MSA  phase.  The  ITR 
attempts  to  ensure  that  a  program’s  technical  baseline  can  support  a  valid  cost  estimate 
(evaluating  cost  risk),  and  assesses  the  capability  needs  and  materiel  solution  approach  of 
a  proposed  program. 

The  ASR  is  a  technical  review  that  tries  to  ensure  that  the  elicited  set  of 
requirements  agrees  with  the  customers’  needs  and  expectations  and  that  the  system 
under  review  can  proceed  into  the  Technology  Development  phase.  The  ASR  is 
important  because  it  attempts  to  minimize  the  number  of  requirement  that  will  need  to  be 
changed  in  later  phases.  The  ASR  should  be  completed  prior  to,  and  provide  information 
for  Milestone  A  [46]. 

b.  Materiel  Solution  Analysis  Phase  Outputs 

Some  of  the  outputs  from  the  MSA  phase  include:  Preliminary  System 
Specification;  Test  and  Evaluation  Strategy;  SEP;  and  Inputs  to  draft  Capability 
Development  Document  (CDD)  and  AoA. 
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2,  Technology  Development  Phase 

Figure  21  shows  that  in  this  phase  “A”  and  “B”29  people  interaet  in  an  attempt  to 
mature  teehnologies  into  an  end-system  configuration.  This  phase  determines  the 
appropriate  set  of  technologies  to  be  used,  conducts  competitive  prototyping,  refines 
requirements,  and  develops  baselines  for  system  configuration. 

According  to  the  DAG,  in  this  phase: 

[SE]  processes  help  mature,  prototype,  and  demonstrate  the  selected 
system  elements  and  complete  the  preliminary  design  of  the  full  system 
for  low-risk  entry  to  the  [EMD]  phase. 

Eigure  23  shows  the  SE  related  steps  that  are  conducted  in  the  TD  phase.  The 
first  step  (step  1)  attempts  to  interpret  the  user’s  need  by  using  the  outputs  from  the 
previous  phase  (some  being  the  ICD,  CDD  draft,  material  solution,  T&E  strategy,  SEP, 
and  TDS).  Additional  analysis  may  be  required  to  ascertain  all  of  the  constraints  (such  as 
operational  environment,  resource-industrial  base,  operation  and  support  budgets,  system 
fielding  date,  technology  base,  and  statutory  constraints).  Key  to  the  TD  effort  is 
ensuring  that  the  required  technologies  are  properly  matured. 


29  From  the  Appendix,  “B”  phase  people  are  engineers  with  technical  experience  that  push  the 
technology  boundaries  with  a  “can  do”  attitude  that  is  at  times  overly  optimistic.  “B”  people  interface  with 
“A”  and  “C”;  therefore  they  need  to  technically  commit  to  “A”  and  make  sure  the  plan  is  feasible  for  “C” 
people  and  encourage  “C”  people  that  this  system  is  doable  (show  them  the  system  vision). 
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Figure  23. 


System  Engineering  Related  Steps  During  Technology  Development  Phase 

(From  [46]) 


The  SE  process  then  steps  through  the  development  of  system  performance 
specifications  and  functional  definitions  (step  2).  There  is  analysis  and  decomposition 
from  the  capability  level  to  the  system  level  and  to  the  functional  level. 

The  next  two  steps  (steps  3  and  4)  decompose  functional  requirements  into  critical 
components  by  evaluating  available  technologies  so  that  they  can  provide  the  required 
functionality.  Then  the  system  functions  are  allocated  into  critical  components  of  the 
systems,  that  will  provide  the  required  functionality.  The  requirements  trade  space  will 
be  used  to  maximize  fidelity  to  the  system  specifications  while  following  program 
constraints  and  program  risk. 

At  the  bottom  of  the  “Vee”  (step  5),  system  concepts  are  developed  and  designed, 
and  prototypes  are  demonstrated  that  show  the  viability  of  the  overall  system  and  where 
critical  technology  maturation  should  occur. 
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Moving  up  the  “Vee”  (steps  6-9),  the  steps  demonstrate:  desired  capability  versus 
component  functionality;  prototype  functionality  versus  system  capability;  integrated 
system  versus  performance  specifications;  and  system  concepts  and  technology  maturity 
versus  defined  user  needs.  Based  on  competitive  prototyping  efforts  adjustments  may  be 
made  to  top-level  requirements  and  revision  may  be  made  to  the  cost  and  schedule 
estimates. 

The  last  three  steps  (steps  10-12)  of  the  SE  TD  phase  are  the  start  of  the 
Integrated  System  Design  effort,  where  the  system  design  transitions  from  system 
concept  to  an  integrated  system  design.  The  PM  needs  to  be  mindful  and  understand  the 
KPP  of  the  system  and  continuously  monitor  cost,  schedule,  and  performance  [46]. 

a.  Technology  Development  Phase  Technical  Reviews 

Technical  reviews  conducted  during  this  phase  include  the  Prototype 
Preliminary  Design  Review  (PPDR)  and  the  Prototype  Critical  Design  Review  (PCDR), 
that  support  the  competitive  prototyping  efforts  and  support  the  technical  approach  and 
program  plans. 

The  System  Requirement  Review  (SRR),  the  first  of  three  reviews  used  to 
start  integrated  system  design,  ensures  that  the  system  under  review  can  proceed  into 
initial  system  development  by  verifying  that  system  requirements  are  consistent  with  the 
materiel  solution.  According  to  the  DAG: 

The  SRR  confirms  that  the  user’s  operational  requirements  are  sufficiently 
well  understood  and  have  been  translated  into  system  specific  technical 
requirements  to  permit  the  developer  (contractor)  to  establish  an  initial 
system  level  requirements  baseline  [46]. 

The  System  Functional  Review  (SFR)  ensures  that  the  systems’  functional 
baseline  is  established,  and  can  satisfy  the  requirements  of  the  CDD.  This  review 
assesses  the  decomposition  of  the  system  specification  to  system  functional 
specifications.  It  completes  the  definition  of  items  below  the  system  level.  According  to 
the  DAG: 
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The  SFR  determines  whether  the  system’s  functional  definition  is  fully 
decomposed  to  its  lower  level,  and  that  [IPTs]  are  prepared  to  start 
preliminary  design  [46]. 

In  addition,  the  SFR  determines  whether  the  system’s  lower-level 
performance  requirements  are  consistent  with  the  system  concept,  and  whether  lower- 
level  systems  requirements  trace  to  top-level  system  performance  and  the  draft  Capability 
Development  Document  (CDD). 

The  Preliminary  Design  Review  (PDR),  according  to  the  DAG,  is: 

A  technical  assessment  establishing  the  physically  allocated  baseline  to 
ensure  that  the  system  under  review  has  a  reasonable  expectation  of  being 
judged  operationally  effective  and  suitable.  The  PDR  establishes  the 
allocated  baseline  (hardware,  software,  human/support  systems)  and 
underlying  architectures  to  ensure  that  the  system  under  review  has  a 
reasonable  expectation  of  satisfying  the  requirements  within  the  currently 
allocated  budget  and  schedule,  [46]. 

The  PDR  determines  if  the  subsystem  requirements  correctly  implement 
the  system  requirements  and  it  traces  subsystem  requirements  to  system  design. 

Technology  Readiness  Assessment  (TRA),  and  output  of  the  TD  phase,  is 
a  requirement  for  regulatory  information  for  all  acquisition  programs.  The  TRA  assesses 
the  maturity  of  Critical  Technology  Elements  (CTE).  CTE  are  technologies  that  are  new 
or  novel  and  that  a  system  depends  on  to  meet  requirements  in  development,  production, 
or  operation.  The  TRA  is  a  tool  for  assessing  “program  risk  and  the  adequacy  of 
technology  maturation  planning”  [46].  The  TRA  scores  the  current  readiness  level  of 
developed  system  elements,  using  defined  Technology  Readiness  Eevels  (TRL). 

b.  Technology  Development  Phase  Outputs 

Some  of  the  outputs  from  the  TD  phase  include:  TEMP;  SEP;  TRA;  Inputs 
to  the  CDD  and  the  Acquisition  Strategy;  and  PDR  Report. 
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3,  Engineering  Manufacturing  Development  Phase 

Figure  21  shows  that  in  the  EMD  phase  “B,”  “C”30,  and  “D”3i  people  interact  in 
attempts  to  complete  the  development  of  a  system  or  increment  of  capability,  reduce 
integration  and  manufacturing  risk,  integrate  sub-systems,  and  design  for  producibility. 
Since  it  begins  after  the  Milestone  B  decision  this  phase  is  considered  the  program 
initiation. 

Figure  24  shows  the  SE  process  steps  in  the  EMD  phase.  The  SE  process  attempts 
to  complete  the  integrated  system  design,  any  remaining  initial  system  design,  and  reduce 
system  level  risk.  Key  to  this  phase  is  successful  performance  in  integrated  tests, 
developmental  evaluations,  operational  assessments,  and  the  use  of  Modeling  and 
Simulation  (M&S)  in  T&E. 

The  first  SE  step  of  this  phase  finalizes  the  detailed  design  of  the  system  by 
evolving  the  component,  or  Cl,  design  into  system  product  baseline.  The  detailed  design 
of  the  system  includes  all  hardware  and  software  components. 

Step  2  involves  the  fabrication  of  hardware  components  and  software  coding, 
acquisition  of  other  components  (commercial,  re-use,  etc),  and  the  assembly  of  the 
components.  If  a  technology  is  not  mature  enough  to  use  in  the  current  iteration  of  the 
system,  an  alternate  technology  is  identified,  to  mitigate  the  associated  risk. 


30  From  the  Appendix,  “C”  phase  people  are  also  engineers.  They  are  experts  in  the  sub-system 
technical  areas.  The  best  “C”  phase  people  often  move  to  work  in  the  “B”  phase. 

31  From  the  Appendix,  The  “D”  phase  people  are  the  leaders  from  the  “A,  B,  and  C”  phases  that 
understand  the  sub-systems  and  how  they  will  interact  when  integrated  into  the  whole  system.  They  are 
determined  to  make  the  system  work  and  will  work  night  and  day  to  achieve  successful  systems. 
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Figure  24.  System  Engineering  Related  Steps  During  the  Engineering  and  Manufaeturing 

Development  Phase  (From  [46]) 

Step  3  evaluates  individual  CIs  by  eondueting  unit  testing  and  evaluation  of 
hardware  and  verification  and  validation  of  software.  Components  are  tested  in  their 
operational  environment.  Risk,  cost,  and  schedule  assessments  continue  as  mitigation 
solutions  to  integration,  validation,  and  verification  issues  feedback  to  the  refinement  of 
the  design. 

Step  4  evaluates  individual  CIs  by  conducting  unit  testing  and  evaluation  of 
hardware  and  verification  and  validation  of  software.  Components  are  tested  in  their 
operational  environment.  Risk,  cost,  and  schedule  assessments  continue  as  mitigation 
solutions  to  integration,  validation,  and  verification  issues  feed  back  to  the  refinement  of 
the  design. 
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The  next  three  steps  (steps  5-7)  eonduet  integrated  tests  that  verify  eomplianee  to 
subsystem  speeifications,  integrated  system  performanee  and  functionality  requirements, 
and  integrated  system  verification  against  specified  operational  requirements.  Risk,  cost, 
performance,  and  schedule  continue  to  be  monitored.  Any  interface  and  interoperability 
issues  for  the  system  are  continually  addressed,  in  order  to  ensure  that  the  system  is  able 
to  achieve  its  interoperability  certification.  These  steps  confirm  that  the  manufacturing 
processes  are  under  control  and  any  technical  risks  are  mitigated. 

a.  Engineering  Manufacturing  Development  Phase  Technical 
Reviews 

Technical  reviews  conducted  during  the  EMD  phase  include  the:  Critical 
Design  Review  (CDR),  Test  Readiness  Review  (TRR),  Functional  Configuration  Audit 
(FCA),  System  Verification  Review  (SVR),  and  Production  Readiness  Review  (PRR). 

The  CDR  is  a  technical  review  that  establishes  the  initial  product  baseline, 
ensuring  that  the  system  can  satisfy  the  requirements  of  the  CDD.  A  CDR  is  normally 
conducted  for  each  sub-system,  or  component,  and  culminates  in  a  system  level  CDR  that 
approves  the  product  baseline  for  the  entire  system.  There  are  incremental  levels  of 
CDRs,  and  they  range  from  component.  Cl,  to  system  level.  The  CDR  evaluates  the 
proposed  “Build  To”  documentation  to  determine  if  it  can  start  initial  manufacturing. 
Once  the  product  baseline  is  established  the  ability  to  change  life-cycle  cost  or  improve 
performance  is  reduced. 

The  TRR  is  a  review  that  ensures  that  the  sub-system  or  system  is  ready  to 
proceed  into  formal  testing.  The  TRR  verifies  the  traceability  of  test  requirements  to  user 
needs  and  also  assesses  the  system  for  development  maturity,  cost,  schedule  and  risk. 

The  SVR  is  a  product  and  process  assessment  to  ensure  the  system  can 
proceed  into  Fow-Rate  Initial  Production  (FRIP)  and  Full-Rate  Production  (FRP).  It 
evaluates  cost,  schedule,  risk,  and  other  system  constraints. 

The  FCA  tests  characteristics  of  Cl  (hardware  and  software),  attempting  to 
verify  that  actual  performance  complies  with  design  and  interface  requirements.  During 
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the  FCA,  a  review  of  the  configuration  item’s  test/analysis  data  is  conducted  to  validate 
that  the  stated  function  or  performance  is  met.  A  successful  FCA  demonstrates  that  an 
EMD  product  is  sufficiently  mature  for  entrance  into  LRIP. 

The  PRR  determines  if  the  program  design  is  ready  for  production.  It 
checks  if  prime  contractor  and  its  subcontractors  have  incurred  unacceptable  risks  that 
affect  production  (schedule,  performance,  cost)  of  the  project.  The  PRR  verifies  that 
system  requirements  are  traceable  to  the  final  production  system.  The  PRRs  are 
conducted  iteratively,  and  the  “final”  PRR  should  occur  at  the  completion  of  the  EMD 
phase  and  should  asses  the  manufacturing  and  quality  risk  as  the  system  proceeds  into 
ERIP  [46]. 


b.  Engineering  Manufacturing  Development  Phase  Outputs 

Some  of  the  outputs  from  the  EMD  phase  include:  Product  Baseline;  Test 
Reports;  TEMP;  SEP;  Inputs  to  the  Capability  Production  Document  (CPD),  and  Cost 
and  Manpower  Estimate. 

4,  Production  and  Deployment  Phase 

Eigure  21  shows  that  in  the  PD  phase  “E”32,  “p,”  and  “G”33  people  interact  in 
attempts  to  achieve  operational  capability  of  the  system  in  a  way  that  satisfies  the  mission 
needs.  The  PRP  Decision  Review  (PRP  DR)  separates  the  ERIP  and  ERP  efforts.  SE 
processes  are  used  to  reduce  program  risk  and  identify  potential  management  issues  in  a 
timely  manner.  According  to  the  DAG: 

As  the  integrated  components  develop  into  a  system,  the  test  and 
evaluation  processes  frequently  reveal  issues  that  require  improvements  or 
redesign.  As  the  testing  environment  more  closely  approaches  that  of  the 
users  needs,  the  required  improvements  might  be  complex  and/or  subtle 
[46]. 


32  From  the  Appendix,  “E”  phase  people  like  to  “clean-up”  the  system  design  by  documenting 
configurations,  developing  end-user  training  documents,  and  cleaning  up  design  issues.  These  people 
usually  are  writers  and  enjoy  developing  documentation,  for  example  training  documents,  etc. 

33  From  the  Appendix,  “F,”  “G,”  “Ft,”  “I,”  and  “J”  people  are  associated  with  life-cycle  support,  carry 
out  production,  ensure  maintenance,  perform  upgrades,  provide  support,  and  who  plan  for  retirement  and 
disposal  of  the  system. 
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Figure  25  shows  the  SE  steps  performed  during  the  PD  phase.  In  the  first  step, 
known  system  deficiencies  (from  all  inputs  available)  are  analyzed  and  a  solution  is 
proposed.  A  plan  to  build,  modify,  verify,  test,  and  evaluate  the  system  is  formulated. 

The  next  step  takes  the  proposed  solution  to  the  deficiencies  and  translates  them 
into  hardware  or  software  specification  changes.  Cost,  schedule,  and  performance 
impacts  are  considered  for  the  designed  system,  but  a  retrofit  will  also  be  considered 
because  production  of  the  system  has  already  begun  (system  is  in  TRIP  or  FRP). 


The  last  step  verifies  and  validates  the  proposed  changes  as  they  apply  to  the 
current  configuration  of  the  system. 
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Figure  25.  System  Engineering  Related  Steps  During  the  Production  and  Deployment 

Phase  (From  [46]) 


a.  Production  and  Deployment  Phase  Technical  Reviews 

Technical  reviews  conducted  during  the  PD  phase  include  the;  Operational 
Test  Readiness  Review  (OTRR);  and  the  Physical  Configuration  Audit  (PCA).  The 
OTRR  ensures  that  the  system  can  successfully  proceed  into  lOT&E,  a  decision  made  by 
the  Service  Acquisition  Executive.  The  FRP  decision  sometimes  hinges  on  this  technical 
review. 
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The  PCA  is  conducted  around  the  time  that  FRP  begins,  and  it  verifies  that 
the  related  design  documentation  matches  what  was  specified  in  the  contract.  The  PCA 
also  validates  many  of  the  supporting  processes  (manufacturing,  quality  control,  testing, 
and  training)  that  are  used  in  the  system  production. 

b.  Production  and  Deployment  Phase  Outputs 

Some  outputs  from  the  PD  phase  are:  Updated  Product  Baseline; 
Evaluation  results  from  test;  TEMP;  Eife-cycle  Sustainment  Plan;  and  SEP. 

5.  Operations  and  Support  Phase 

The  OS  phase  executes  the  support  program  that  sustains  the  system  in  a  cost- 
effective  manner  over  the  total  life-cycle  and  eventually  disposes  of  the  system. 

The  SE  process  steps  in  the  OS  phase  support  in-service  reviews  where  trade 
studies  will  be  used  to  determine  the  best  resolution  to  solve  safety,  readiness  degrading, 
and  improvement  (modifications  and  upgrade)  issues. 

Eigure  26  shows  the  SE  steps  performed  in  the  OS  phase.  The  first  step  monitors 
and  collects  service  use  data.  Since  many  systems  stay  in  service  much  longer  than 
originally  anticipated,  operations  and  support  decision  will  change  as  operational 
understanding  of  the  system  matures. 

Step  2  analyzes  data  from  problems  that  arise  in  the  fielded  system.  As  root 
causes  are  determined,  potential  solutions  are  developed. 

The  next  two  steps  (steps  3-4)  determine  the  system  risk,  the  hazard  probability 
and  severity  and  also  develop  corrective  action.  The  corrective  actions,  mitigation 
measures,  can  encompass  hardware,  software,  support,  materiel,  or  maintenance  changes. 

The  next  three  steps  (steps  5-7)  integrate  and  test  the  corrective  action  to  ensure 
that  it  solves  the  issue.  In  addition,  they  assess  the  risk  of  the  improved  system  once 
corrective  action  is  demonstrated  as  effective,  and  then  long-range  system  ramifications 
and  life-cycle  costs  are  addressed. 
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Figure  26.  System  Engineering  Steps  During  the  Operations  and  Support  Phase  (From 

[46]) 

a.  Operations  and  Support  Phase  Technical  Reviews 

Teehnical  reviews  during  the  OS  phase  include  the  In-Service  Review 
(ISR).  The  ISR  assesses  the  in-service  health  of  the  system.  According  to  the  DAG,  it: 

Provides  an  assessment  of  risk,  readiness,  technical  status,  and  trends  in  a 
measurable  form.  These  assessments  substantiate  in-service  support 
budget  priorities  [46]. 

b.  Operations  and  Support  Phase  Outputs 

Outputs  of  the  SE  processes  in  the  OS  phase  include:  input  to  ODD  for 
next  design  increment;  Modification  and  upgrades  to  fielded  system;  data  for  ISR;  and 
SEP. 
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D,  CONCLUSIONS 

This  chapter  has  presented  the  SE  approaeh  to  aequisition.  Several  different  SE 
processes  were  discussed,  and  then  a  generie  SE  approaeh  was  mapped  to  the  latest 
version  of  the  DoD  aequisition  proeess. 

The  next  chapter  will  present  the  Network-Centrie  Aequisition  Proeess  (NCAP) 
and  will  give  a  detailed  deseription  of  the  theories  on  whieh  the  NCAP  are  based,  and 
deseribe  how  the  NCAP  will  operate. 
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V.  NETWORK-CENTRIC  ACQUISITION  PROCESS 


The  Network-Centric  Acquisition  Process  (NCAP)  will  be  presented  in  this 
chapter.  Chapters  I-IV  have  laid  the  foundation  on  which  the  NCAP  will  be  built: 
network-centric  theory,  DoD  acquisition  process,  and  SE  processes. 

NCAP  focuses  on  acquiring  the  “glue”34  that  makes  networked  systems  network¬ 
centric.  NCS  range  from  a  ship  (ECS)  to  a  large  network  (the  GIG)  to  an  unmanned 
aerial  vehicle  (e.g.,  the  Predator  UAV),  the  common  thread  that  makes  these  systems 
network-centric  is  their  ability  to  harness  the  power  of  the  network  to  gain  information 
and  decision  superiority  over  an  adversary. 

NCAP’s  goal  is  to  deliver  capability  quickly  to  the  warfighter,  with  the  promise  of 
follow-on  fast  incremental  capability  upgrades.  Current  DoD  acquisition  process  is  serial 
delivers  large  chunks  of  capability,  it  is  expensive,  has  slow  refresh  cycles,  and  ensures 
that  processes  and  systems  be  stovepiped.  NCAP  will  provide  the  framework  for  faster 
acquisition  by  focusing  on  speed-to-capability,  speed-to-better-capability.  Valued 
Information  at  the  Right  Time  (VIRT),  component  reuse,  and  Value  Off-The-Shelf 
(VOTS)  [49]  [26]. 

NCAP  is  an  SE  based  process  where  customers  and  developers  work  closely 
together  to  define  the  requirements,  the  development  of  products  uses  best  industry 
practices  and  is  iterative,  and  the  integration  of  products  is  done  in  an  environment  that 
tests  products  frequently.  The  NCAP,  as  proposed  in  this  chapter,  is  not  currently  used 
by  DoD35,  but  its  successful  implementation  in  the  private  commercial  sector^^  is  one  of 
many  compelling  reasons  for  its  adoption  in  the  DoD. 


^4  Network-centric  “glue”  is  analogous  to  the  network-centric  infrastructure  on  which  the  NCS  are 
able  to  achieve  information  superiority,  decision  superiority,  and  full  spectrum  dominance.  The  “glue”  is 
the  network-centric  IT  that  supports  NCS. 

35  The  DoD  has  used  aspects  of  the  NCAP  in  Aegis  combat  systems  software  acquisition,  but  no 
evidence  of  DoD  usage  of  a  NCAP  was  found  during  research  of  this  thesis  topic. 

3^  NCAP  has  been  successfully  implemented  by  Apple  Inc.  for  applications  used  for  the  iPhone.  eBay 
and  Amazon  have  also  successfully  implemented  NCAP. 
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The  rest  of  this  chapter  will  discuss  the  framework  of  NCAP,  and  then  map  the 
NCAP  to  the  NCSE  core  diagram,  which  was  presented  in  Chapter  II.  Then  the  chapter 
will  describe  in  detail  NCAP’s  parts,  which  include  a  set  of  evaluation  metrics, 
component  reuse,  collaborative  environment,  acquisition  data  repository,  electronic 
business  marketplace,  and  Off-The-Shelf  (OTS)  components.  Once  the  framework  of 
NCAP  is  laid  out,  the  last  parts  of  this  chapter  will  present  a  DAS  level  acquisition  model 
forNCS37. 

A,  NETWORK-CENTRIC  ACQUISITION  PROCESS  AND  THE  NETWORK¬ 
CENTRIC  SYSTEMS  ENGINEERING  CORE 

The  NCSE  core  diagram  was  presented  in  Chapter  II,  and  was  used  to  describe  a 
SoS38  that  uses  four  approaches  to  achieve  network-centricity.  The  NCSE  core  diagram 
is  a  useful  way  to  understand  how  NCS  operate.  It  is  also  useful  in  understanding  how 
the  NCSE’s  four  separate  approaches  (top-down,  bottom-up,  middle  approach,  and 
disadvantaged  user),  are  all  integrated  by  the  NCSE  core  (Networks,  distributed 
computing,  and  real-time  processing)  into  a  SoS.  This  NCSE  core  will  be  used  to 
recommend  an  NCAP  framework. 

The  NCAP  can  also  be  regarded  as  a  SoS  that  uses  several  framework  approaches 
(data  repository,  electronic  business  (e-Biz)  marketplace,  development  environment,  etc.) 
that  are  all  integrated  to  achieve  network-centricity  for  the  acquisition  process. 

Eigure  27  shows  the  mapping  of  the  NCAP  onto  the  NCSE  core  diagram.  The 
customer  requirements^^,  component  reuse,  data  repository,  e-Biz  marketplace,  and 
Government  Eumished  Equipment  (GEE)40  occur  in  the  top-down  approach.  The 
network-centric  applications  created  by  developers,  the  development  standards,  and  the 


37  This  model  was  developed  by  the  Defense  Science  Board  and  recommended  to  replace  the  DoD 
Directive  5000.01  model  [50]. 

3^  NCSE  core  is  a  SoS  because  it  is  made  up  of  systems  that  can  operate  independently,  but  when 
integrated  make  the  system  network-centric.  It  could  be  argued  that  the  top-down,  bottom-up,  middle,  and 
disadvantaged  user  approach  are  all  systems  in  the  NCSE  core,  therefore  making  it  a  SoS. 

39  Customer  requirements  refer  to  the  “network-centric”  needs. 

Government  furnished  equipment  (GEE)  is  equipment  (hardware  and/or  software)  that  is  made 
available  to  NCAP  developers  for  their  use  in  innovating  and  developing  network-centric  systems. 
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available  Government  OTS  (GOTS)  oeeur  during  the  bottom-up  approaeh.  The  push/pull 
of  database  seareh  information,  upload/download  database  items  and  e-Biz  marketplaee 
items,  and  finaneial  transaetions  oeeur  in  the  middle  approaeh.  The  network-eentrie 
applieations  of  non-vetted  or  non-interfaeed  developers  and  OTS  eomponents,  exist  in  the 
disadvantaged  user  approaeh.  This  is  beeause  they  are  not  easily  able  to  get  aeeess  to  the 
NCAP,  and  therefore,  aequisition  of  those  network-eentrie  applieations  is  handled 
differently. 

In  summary,  the  reeommended  NCAP  framework  will  have  the  following: 
metries;  eomponent  reuse;  a  eollaborative  development  environment;  a  data  repository; 
an  eleetronie  business  (e-Biz)  marketplaee;  OTS  eomponent  use;  open  system  and  open 
lieense;  and  eertifieation  and  lA  proeesses.  The  ehapter  provides  details  on  elements  that 
eomprise  the  NCAP  framework. 
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Figure  27.  Mapping  of  the  NCAP  to  the  NCSE  eore  diagram  (From  [27]) 
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B,  ACQUIRING  THE  NETWORK-CENTRIC  “GLUE” 

As  discussed  in  Chapter  I,  NCS  gain  their  effeetiveness  from  harnessing  the 
power  of  the  eonneeted  network  nodes  and  support.  Therefore,  as  the  number  of  nodes 
inerease,  Blue  forees  gain  decision  superiority  over  an  adversary.  Or,  as  Gunderson 
summarized  the  traditional  NCW  hypothesis,  “[a]  foree  with  the  most  networked 
eonnectivity  to  relevant,  timely,  and  aecurate  data  is  the  most  ‘powerful’  ”  [4]. 

Although  NCS  ean  be  platforms,  weapons,  sensors,  or  systems,  NCAP  will  focus 
on  acquiring  that  which  makes  NCS  network-eentrie,  i.e.,  the  network-eentric 
Information  Technology  (IT).  In  other  words,  NCAP  is  about  aequiring  the  network- 
eentric  “glue”  that  enables  the  network  and  support  network-eentrieity.  “Glue”  is  the 
integration  of  all  parts  in  Figure  27. 

C.  NETWORK-CENTRIC  ACQUISITION  PROCESS  OVERVIEW 

The  DoD  is  slow  in  delivering  the  required  eapabilities  to  the  end-user,  taking  10 
to  15  years  to  get  from  program  start  to  eomponent  produetion  [51],  and  thus  often 
delivering  eapabilities  to  the  warfighter  that  are  outdated  or  obsolete.  This  is  reinforeed 
by  Bob  Arbetter,  Direetor,  Colleetion  Concepts  &  Strategies,  Offiee  of  the  Deputy 
Underseeretary  of  Defense  for  Intelligenee,  who  said  that  “slow  aequisition  equals 
obsolete  teehnology”  [52].  In  the  eurrent  warfighing  environment  that  ineludes  the 
Global  War  on  Terror  (GWOT),  it  is  eritieal  to  get  up-to-date  eapabilities  to  the 
warfighter  quickly.  In  order  for  the  DoD  to  deliver  leading  edge  technology  to  the 
warfighter,  it  needs  to  use  an  aequisition  proeess  that  delivers  needed  eapabilities  faster, 
eheaper,  and  with  frequent  refresh  cyeles.  NCAP  is  the  solution  that  will  ehange  DoD 
aequisition  from  slow,  serial,  and  massive,  to  fast,  parallel,  and  ineremental. 

The  next  subseetions  will  deseribe  the  qualities  needed  in  the  NCAP. 
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1.  Fast  Acquisition 

NCAP  can  facilitate  fast^i  acquisition  by  leveraging  the  reuse  of  existing 
teehnology,  mandating  use  of  “Open  Modular  Design”  produets  [39]  [53]  [54], 
eneouraging  maximal  use  of  Commereial  OTS  (COTS)  products  and  enabling 
eollaborative  and  open  eompetition. 

2.  Parallel  Development 

Parallel  development,  viee  serial  development,  attempts  to  address  and  eorrect  the 
ineffieient  way  in  whieh  DoD  systems  have  been  developed.  As  diseussed  in  Chapter  III, 
all  DoD  aequired  systems  go  through  the  following  steps:  they  are  designed;  built;  tested; 
V&V;  and  supported  throughout  the  system’s  life-eyele.  Current  DoD  aequisition 
eonduets  eaeh  step  in  series  (e.g.,  finish  design  of  system,  then  build,  then  test,  ete.). 

Parallel  development  advoeates  implementing  short  iterative  development  cyeles 
of  the  system  aequisition  steps  almost  in  parallel  (e.g.,  at  the  same  time).  Parallel 
development  would  speeifieally:  design  a  segment  of  the  system;  build  the  segment;  test 
the  segment  (e.g.,  for  interoperability);  V&V  the  segment;  and  develop  the  life-eyele 
support  plan  for  the  segment.  Segments  are  then  integrated  inerementally,  until  the 
system  is  eompleted.  Developing  produets  in  this  way  is  efficient,  beeause  integration 
and  testing  of  the  system  is  eonducted  continuously  throughout  the  development  of  the 
system,  and  therefore,  integration  and  testing  issues  can  easily  be  correeted  with  minor 
system  modifieations. 

3.  Incremental  Acquisition 

Incremental  acquisition  prioritizes  timeliness  of  capability  delivery  over  the 
amount  of  capability  delivered.  Incremental  acquisition  is  made  a  reality  by  NCAP’s 
frequent  upgrade  cycles. 


Fast  implies  that  the  aequisition  takes  less  time  or  less  effort  to  eomplete.  This  statement  is  made 
with  the  assumption  that  the  reuse  of  eomponents,  use  of  “open”  produets,  maximal  use  of  COTS  produets, 
and  eneouraging  eollaborative  and  open  eompetition  will  foster  an  environment  of  innovation  that  spurns 
fast  and  effieient  produet  development. 
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D,  NETWORK  CENTRIC  ACQUISITION  PROCESS  METRICS 

DoD  acquisition  is  a  business,  and  the  business  of  providing  “global  security” — 
defense  systems — is  difficult,  challenging,  and  eomplex,  but  it  is  important  that  it  be 
earned  out  correetly.  The  complexities  of  DoD  aequisition  are  not  excuses  for  bad 
business  practiees.  In  industry,  good  business  praetiees  depend  on  managing  a 
“dashboard” — measuring  metrics — that  link  customer  concerns  with  the  proeesses  that 
the  enterprise  or  business  can  use  to  address  them.  Thus,  the  NCAP  model  should  focus 
on  delivering  better  capability  faster.  That  is,  not  only  improving  speed-to-capability,  but 
also  improving  the  value  of  the  capability  delivered.  Hence,  the  traditional  jargon 
“speed-to-capability”  becomes  “better-speed-to-hetter-capability.”  The  NCAP 
“dashboard”  then  seeks  to  objeetively  define,  monitor,  and  adjust  “better”  with  respect  to 
required  speed,  and  with  respect  to  required  eapability. 

The  next  two  subsections  will  present  two  metrics  that  will  be  used  with  the 

NCAP. 


1,  Better  Speed-to-Capability  Metric 

The  DoD  needs  a  metrie  to  measure  how  quickly  a  capability  is  developed  and 
fielded — “better”  speed-to-capability.  In  the  network-eentric  world,  this  metrie  measures 
the  speed  with  whieh  net-ready  capabilities  are  developed. 

The  Defense  Aequisition  University  (DAU)  defines  net-ready  as  a: 

[National  Security  System  (NSSj)  that  meets  required  information  needs, 
information  timeliness  requirements,  has  information  assurance 
acereditation,  and  meets  the  attributes  required  for  both  the  technical 
exchange  of  information  and  the  end-to-end  operational  effectiveness  of 
that  exehange  [and]  enables  [users]  to  exereise  control  over  enterprise 
information  and  services  through  a  loosely  coupled,  distributed 
infrastrueture  that  leverages  service  modularity,  multimedia  conneetivity, 
metadata,  and  collaboration  to  provide  an  environment  that  promotes 
unifying  actions  among  all  participants.  [55] 
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Gunderson^^  gt  al.  explain  that  traditional  acquisition  metrics  are  called  “Key 
Performance  Parameters”  (KPP).  The  KPP  traditionally  used  to  define  “Sustainability”  is 
called  “Operational  Availability”  with  shorthand  notation  of  Aq.  They  suggest  that 
better-speed-to-capability  is  required  to  sustain  an  NCS  throughout  its  life-cycle.  Hence 
they  abstract  the  notion  of  Aq  to  define  a  metric  to  measure  speed-to-capability  of  net- 
ready  systems  they  call  Anr^^,  availability  of  net-ready  capability  [56]. 

Gunderson  et  al.  have  advocated  using  Anr  as  a  way  to  evaluate  net-ready 
acquisition  process-level  Measures  Of  Effectiveness  (MOE).  A^  measures  the  speed-to- 
capability  of  net-ready  acquisitions,  providing  a  metric  that  focuses  on  the  network¬ 
centric  acquisition  priority  of  speed. 

/W  =  DTi  /(CDT  =  { DTc  +  TT^  +  CTc) ) 

Where: 

Aflr=  Net-Re|ady  Availability:  a  unit-less  index  that  compares  the  obsolescence  rate  of  the 
technology  to  how  quickly  the  capability  can  be  deployed  and  certified  as  secure  and 
interoperable 

DTi=  Initial  estimated  Development  Time:  calendar  time  required,  in  consideration  of  testing 
and  certification  time  lines,  to  field  an  increment  of  IT  capability  prior  to  its  obsolescence. 

CDT  =  Capability  Deployment  Time:  best  current  estimate  of  the  total  calendar  time  it  will  take 
from  commencement  of  development  until  increment  of  IT  capability  is  fielded. 

DTc=  Current,  or  revised  estimate  of  Development  Time  at  the  time  of  evaluation 

TTc=  Current  or  revised  estimate  of  Test  Time:  calendar  time  required  post  development  to 
complete  any  additional  required  testing. 

CTc  =  Current  or  revised  estimate  of  Certification  Time:  calendar  time  required  post  testing  to 
achieve  any  necessary  certifications. . 

Eigure  28.  Anr  Defined  (Erom  [56]) 


Chris  Gunderson,  Captain  (retired)  U.S.  Navy,  is  Prineipal  Investigator  of  the  Naval  Postgraduate 
School  W2COG  and  Netcentric  Certification  Office  initiatives.  He  is  also  a  Research  Associate  Professor 
in  the  Department  of  Information  Science  at  Naval  Postgraduate  School. 

A„r  is  a  number  between  0.00  and  1.0.  An  An,  value  closer  to  1.0  is  always  desirable,  but  impossible 
to  achieve. 
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Anr  measures  the  ratio  of  the  Initial  Estimated  Development  Time  (DTi)  over  the 
Capability  Development  Time  (CDT).  Figure  28  explains  how  Anr  is  calculated  and 
defines  all  of  its  terms.  A  better  way  to  look  at  the  Anr  formula  is: 

Anr=DTi/CDT,  where  CDT=(DTe+  TT^  +CTe) 

Anr  measures  the  acquisition  processes  effectiveness  at  delivering  speed-to- 
capability.  Better  stated,  A^  is  a  measure  to  compare  technology  obsolescence  rates  with 
capability  development  time,  thus  allowing  the  PM  manager  know  if  a  product  will  be 
acquired  that  has  obsolete  technology ^4.  Ideally: 

•  The  Initial  Estimated  Development  Time  (DTi)  would  be  perfectly 
accurate,  and 

•  Testing  and  Certification  (TTc  and  CTc)  would  occur  perfectly  in  parallel 
with  development. 

In  that  ideal  case,  DTi  and  CDT  would  be  equal  and  yield  an  Anr  of  unity45. 
However,  at  any  given  phase  of  a  realistic  project,  the  revised  estimate  of  CDT  generally 
becomes  larger  than  the  initial  development  time  estimate,  DTi.  Therefore,  as  the 
increment  of  development  progresses,  the  current  calculated  value  of  A^  will  likely 
decrease.  If  it  decreases  below  a  predefined  threshold  value,  the  program  is  in  danger  of 
missing  its  speed-to-better-capability  goal,  and  must  re-scope  the  deliverables 
accordingly.  This  metric  is  useful  because  it  gives  the  PM  or  acquisition  manager  the 
ability  to  objectively  evaluate  the  efficiency  of  the  acquisition  process  to  quickly  field 
relevant  (leading  edge)  systems. 

Gunderson  et  ah,  suggest  notionally  that  a  good  target  value  of  CDT  should  be 
consistent  with  Moore’s  Eaw — eighteen  months.  A  good  target  value  for  DTi  might  be 
twelve  months — the  time  it  typically  takes  to  field  a  pure  COTS  solution  across  a  large 


44  The  equation  itself  does  not  directly  address  obsolescence  rates.  Assuming  Moore’s  Law — eighteen 
months — is  applicable,  then  the  longer  it  takes  to  develop  a  product,  the  more  likely  it  is  that  the  product’s 
technology  will  be  obsolete. 

45  Even  better  would  be  if  the  revised  estimate  of  Development  Time  were  less  than  the  original 
estimate!  In  that  case  Anr  would  be  greater  than  one. 
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enterprise.  Those  values  yield  a  notional  target  value  for  Am  of  0.66^6  [56]  that  should 
be  the  threshold  value  below  whieh  a  PM  should  begin  to  eonsider  alternative  aequisition 
plans  beeause  the  evaluated  aequisition  will  deliver  a  produet  that  is  teehnologieally 
obsolete^^. 

The  following  two  examples  illustrate  how  to  use  to  evaluate  an  aequisition 
deeision. 


a.  Example  One-Threshold  Example 

While  a  PM  might  set  his  objective  at  delivering  his  eapability  inerement 
within  one  Moore’s  Law  eyele  of  eighteen  months,  he  might  set  his  threshold  at  twiee 
that  time.  In  that  ease  he  might  set  (DTi)  at  three  years.  He  might  estimate  three  years  to 
for  the  current  development  time  (DTc),  a  year  to  test  it  (TTc),  and  6  months  to  certify  it 
(CTc).  This  results  in  a  net-ready  availability  of: 

Am=  3/(3  +  1  +  .5)  =  0.66 

These  values  of  Am  and  CDT  are  perhaps  reasonable  thresholds  [56]. 

b.  Example  Two 

Now  suppose  the  same  PM  experiences  delays  similar  to  those  of  the 
Army’s  Future  Combat  System,  say  three  years.  Originally  the  PM  allocated  3  years  to 
develop  the  system  (DTi),  a  year  to  test  it  (TTc),  and  6  months  to  integrate  it  (CTc). 
Taking  into  account  the  expected  delay,  the  following  values  are  entered  into  the 
equation:  DTi=  3  years;  DTc=  6  years  (3  years  original  estimate  +  3  years  of  delay);  TTc= 
1  year;  and  CTc=  .5  years.  Calculating  gives:  We  recalculate: 

Am=  3/(6  +  1  +  .5)  =  0.4 


Intuitively,  the  smaller  Anr  is,  the  longer  it  takes  to  deliver  a  eapability  and  the  more  obsolete  the 
teehnology  will  be.  The  bigger  is,  the  shorter  it  takes  to  deliver  the  eapability  and  the  more  leading 
edge  the  teehnology  will  be. 

Teehnologieally  obsolete  refers  to  systems  that  are  more  than  one  generation  behind  the  most  up-to- 
date  teehnology  (e.g.,  third  generation  iPod  is  obsolete  beeause  there  is  a  fifth  generation  iPod  on  the 
market).  The  goal  of  the  A^  metrie  is  to  allow  the  PM  to  deeide  if  he  should  eontinue  aequiring  a  produet 
that  is  teehnologieally  obsolete,  or  ehange  aequisition  strategy  for  a  more  teehnologieally  advaneed 
produet. 
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Based  on  which  systems  or  components  are  available  commercially,  the 
PM  can  now  objectively  prove  that  his  technology  is  already  a  generation  behind  the 
current — cutting  edge — technology  and  will  likely  deliver  obsolete  technology.  The  PM 
can  take  action  accordingly  (i.e.,  cancel,  down  scope,  deploy  pure  COTS  patch,  etc.), 
rather  than  the  acquisition  of  a  system  that  is  obsolete  [56]. 

Gunderson  et  al.  recommend  that  Anr  of  .66  should  be  used  as  a 
benchmark  below  which  a  PM  should  consider  other  options  to  deliver  the  capability 
[56].  The  Anr  metric  can  also  be  used  to  track  the  reliability  of  the  specific  acquisition  to 
deliver  a  capability  before  its  technology  becomes  obsolete. 

2.  Better  Capability  Metric 

Although  Anr  measures  speed-to-capability,  another  metric  is  needed  that 
measures  the  value  of  the  information  delivered  by  the  NCS.  That  is  we  need  a  metric  to 
define  “better”  capability.  NPS  Professor  Rick  Hayes-Roth  has  developed  an  approach 
he  calls  Valued  Information  at  the  Right  Time  (VIRT)  [26]. 

Gunderson  et  al.  suggest  that  the  metric  to  measure  better-speed-to-better- 
capability  is  Aiv,  i.e.,  information  value  availability,  see  Figure  29.  This  metric  is  the 
product  of  the  Information  Processing  Efficiency  (IPE)  and  the  Delivered  Information 
Value  (DIV)  [56]; 

Aiv=  IPE  X  DIV 

a.  Information  Processing  Efficiency  (IPE) 

IPE  is  a  ratio  of  the  Valued  Bits  processed  (VB)  over  the  Total  Bits 
processed  (TB)  and  multiplied  by  a  perishability  factor  (Wp)"^^.  Otherwise  stated,  this 
measures  how  valuable  the  received  information  (VB)  is  when  compared  to  all  the  data 


Perishability  factor  describes  a  window  of  utility.  The  five-day  forecast  of  a  hurricane  has  a  low 
perishability  factor,  while  the  pinpoint  location  of  a  tornado  has  a  high  perishability  factor.  Wp  is  a 
subjective  value  that  needs  to  be  carefully  assigned  by  the  PM. 
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received  (TB)  and  how  timely  the  data  was  delivered  (Wp).  IPE  measures  the  value  and 
timeliness  of  the  information,  or  “how  easily  and  effectively  disparate  data  from  disparate 
sources  on  network(s)  are  collected  and  bundled  usefully  together  [57].” 

A  good  analogy  for  IPE  is  a  search  for  “weather  forecast  for  Baghdad, 
Iraq”  using  google.com.  Ideal  IPE  would  yield  a  single  result  (VB  =  TB,  and  VB/TB  = 
1.0)  that  would  take  a  fraction  of  a  second  to  display  (Wp=. 99)49. 

IPEideal  Search  (VB/TB)x(Wp)  =  (1.0)x(.99)  =  .99 

In  a  non-network-centric  environment,  the  previous  search  would  yield  ten 
valuable  results  out  of  ten  thousand  results  (VB/TB  =  1/1000  =  .001),  in  a  fraction  of  a 
second  (Wp=.99).  Although  the  results  would  have  a  “relevance”  ranking  and  delivered 
in  a  timely  manner,  the  end-user  would  have  to  devote  valuable  processing  time  to  decide 
which  result  is  the  desired  one. 

IPEnoii  -Network-Centric  Search  (VB/TB)x(Wp)  =  (.001)x(.99)  =  .0099  or  .01 

Although  the  above  example  is  simple,  it  clearly  illustrates  the  power  that 
analyzing  the  IPE  of  different  systems  can  have  on  the  final  decision  of  what  system  to 
acquire. 

Aiv  =  IPE  X  DIV 

IPE  =  (VB  ^TB)  X  Wp 

DIV  =  Pi  X  Pa  X  X  Pn 

where; 

Av  =  Information  Value  Availability 
IPE  -  Information  Processing  Efficiency 
VB  =  Valued  Bits  Processed 
TB  =  Total  Bits  Piocessed 

Wp=  Perishability  factor,  i.e.  describes  time  window  of  utility 
DIV  =  Delivered  Information  Value 

•  Pi . Pn  =  Measured  or  target  scores  re  operational  performance, 

eg.  Probability  of  Kill,  Planning  Cycle  Time.  Logistics  Latency,  etc 


Figure  29.  Aiv  Defined  (From  [56]) 


49  Wp=.99  was  subjectively  chosen,  but  since  it  was  gathered  fast  and  the  information  not  very 
perishable,  a  value  close  to  1 .0  was  chosen.  Highly  perishable  information  would  have  a  Wp  closer  to  zero. 
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b.  Delivered  Information  Value  (DIV) 

DIV  measures  operational  performanee  (see  Figure  29).  Typieally  DIV  is 
represented  with  traditional  military  Measures  of  Effectiveness  (MOE)  or  Measures  of 
Performance  (MOP)  like  “Probability  of  Kill,”  “Circular  Error  Probable,”  “Eratricide” 
statistics,  etc.  Eor  example  if  the  “weather  forecast  for  Baghdad,  Iraq”  turned  out  to  be 
accurate,  it  would  positively  affect  the  probability  of  success  of  a  military  operational 
mission  (where  Ps-initiai(Military  Ops)=.50).  The  positive  impact  of  the  correct  weather 
forecast  would  increase  Ps-initiai(Military  Ops)  say  by  10%^°  to  a  Ps-f,nai(Military 
Ops)Ps=0.55.  If  there  were  many  factors  contributing  to  the  Ps,  then  the  impact  on  each 
factor  (Pi,  P2,  ...Pn-i,  Pn)  would  be  evaluated  individually  and  then  multiplied  together  to 
give  DIV  [57]. 

As  stated  earlier,  the  Aiv  metric  is  the  product  of  IPE  and  DIV  (see  Eigure 
29),  and  could  be  used  to  objectively  compare  different  approaches  to  deliver  the 
“network-centric  glue”  for  a  particular  NCS  to  determine  which  delivers  the  greatest 
information  value.  The  Anr  and  Aiv  metrics  would  be  of  value  to  many  network-centric 
acquisition  stakeholders  as  they  evaluate  different  network-centric  systems  to  acquire. 
These  metrics  would  also  useful  for  evaluating  the  development  status  (cost,  schedule, 
performance)  of  a  NCS  and  to  decide  if  the  acquisition  should  be  cancelled,  modified,  or 
extended. 

The  next  section  of  this  chapter  discusses  the  framework  of  the  NCAP. 

E.  NETWORK-CENTRIC  ACQUISITION  PROCESS  FRAMEWORK 

In  this  section,  the  framework  of  the  NCAP  will  be  discussed.  Although  each  part 
of  the  NCAP  framework  is  presented  individually,  there  is  much  overlap  between  the 
different  framework  parts.  The  overlap  can  be  seen  in  Figure  27. 

The  central  tenet  of  the  NCAP  is  to  provide  not  just  “better”  speed-to-capability 
but  “better”  speed-to-“better”-capability.  The  following  sub-sections  will  describe  how 
these  are  achieved  by:  maximizing  the  reuse  of  components;  using  a  collaborative 

This  example  is  to  show  that  having  the  correct  information  would  increase  the  probability  of 
success.  All  the  probabilities  were  randomly  chosen  to  illustrate  the  use  of  this  metric. 
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development  environment  (where  providers  innovate  and  develop);  ereating  a  data 
repository  that  contains  all  the  data  on  NCS  (design,  software,  hardware  design,  etc.); 
using  an  electronic  business  (e-Biz)  marketplace  (where  customers  and  developers  are 
matched  and  network-centric  products  are  made  available);  where  OTS  product  use  is 
maximized;  where  open  systems  are  available  for  innovation  (open  source,  open 
architecture,  and  open  license);  and  where  developed  items  meet  certification  and  lA 
standards. 

1.  Maximize  Reuse  of  Components 

Maximizing  reuse  of  components  is  a  solution  to  fast  acquisition  (speed-to- 
capability),  but  in  order  to  mandate  reuse  across  intellectual  property  domains,  the  DoD 
must  own  purpose  rights  to  the  designs  and  components^k  The  reuse  of  components  can 
be  seen  in  the  top-down  part  of  the  NCAP  framework  of  Figure  27. 

Best  practices  of  software  development  preach  the  reuse  of  software  (be  it  source 
code,  objects,  or  entire  software  programs)  [50]  [58].  NCAP  framework  encourages 
reusing  software,  systems,  and  components  to  the  maximum  extent  possible  because  it 
reduces  the  acquisition  time,  since  the  reused  items  already  exist  and  do  not  need  to  be 
created. 

In  order  to  facilitate  and  encourage  maximum  software  reuse,  network-centric 
stakeholders  will  need  to  define  and  implement  requirements  (e.g.  standards)  for 
network-centric  interfaces,  interoperability,  software  security,  and  development 
environments  (e.g.  Java,  Windows,  Flash).  Therefore,  the  reuse  of  components  that  do 
not  have  standard  interfaces,  interoperability,  and  security  would  not  be  advocated.  This 
is  because  the  effort  required  by  the  developer  to  make  the  reused  components  compliant 
with  network-centric  standards  could  require  modification  that  would  destroy  the  cost 
savings  that  reuse  could  have  afforded. 
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A  discussion  on  government  purpose  rights  as  they  apply  to  reuse  follows  later  in  this  Chapter. 

78 


The  current  trend  in  DoD  acquisition  is  to  develop  systems  that  use  common 
components,  that  have  standardized  interfaces,  and  meet  minimum  IT  security  standards 
[46].  As  older  “legacy”  systems  are  phased  out  of  the  DoD  inventory,  the  newer  NCS 
and  their  associated  network-centric  components  (software  systems  with  loose  coupling 
and  high  cohesion)  will  become  easier  to  reuse.  The  ease  in  reuse  will  be  due  to  the  way 
software  systems  engineering  designs  maximize  object-oriented  programming  that  allow 
for  a  developers  to  “pull”  software  objects  or  applications,  adapt  them,  and  “plug”  them 
into  the  system  they  are  developing. 

The  reuse  of  components  will  meet  skepticism  from  many  in  the  DoD  and  private 
industry.  Most  NCS  SME  consulted  for  this  thesis  agreed  that  reuse  of  components  is 
good  and  will  eventually  become  a  standard  practice.  Some  SMEs  explained  that 
developers  will  find  it  easier  to  develop  the  applications  or  objects  required  for  the  new 
system  instead  of  taking  the  time  to  search  for  the  item  that  can  be  reused.  The  crux  of 
mastering  the  reuse  issue — making  it  easier  for  developers  to  reuse  network-centric 
components — is  to  be  able  to  effectively  catalog  the  network-centric  components  into  a 
data  repository  that  catalogs  and  stores  components  and  allows  for  efficient  search, 
download  (“pull”)  and  use  or  modification.  The  data  repository  will  be  discussed  in 
detail  later  in  this  chapter,  in  section  C.3;  the  next  NCAP  framework  item  discussed  is  the 
collaborative  development  environment. 

2,  Collaborative  Development  Environment 

The  central  idea  of  the  NCAP  is  to  create  an  environment  where  network-centric 
products  are  developed  using  “best  industry  practices.”  This  development  environment 
would  use  open  systems  that  are  interoperable  and  that  are  developed  in  a  competitive 
environment52.  The  idea  of  a  collaborative  development  environment  comes  from  best 
business  practices  of  public  sector  companies  like  eBay,  Apple  (for  iPhone),  Google  and 
Amazon.  In  these  collaborative  environments,  developers  have  access  to  the  open  source 


52  Competitive  environment  refers  to  an  environment  like  www.eBay.Developer.com  where  open 
source  is  made  available  to  all  members  of  the  environment,  and  where  they  can  compete  with  each  other  in 
developing  a  better  application  for  eBay. 
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code,  an  Application  Programming  Interface  (API)^^^  and  a  language  specific 
programming  environment  (Java,  Flash,  PHP,  etc.).  The  collaborative  development 
environment  can  be  seen  in  Figure  27  as  the  integration  part  of  the  NCSE  eore  (trunk)  of 
the  NCAP  framework  diagram. 

In  the  collaborative  environment,  the  developer  is  given  standards  for  application 
functionality,  interfaces,  and  seeurity,  but  is  left  to  figure  out  how  to  improve  existing 
systems.  If  the  applieation  developed  (e.g.,  component,  software,  systems)  is 
successfully  tested^^^  V&V,  and  provides  value  to  the  “end-user”  or  customers,  it  is  then 
rated  in  a  “eonsumer  reports”  style  format. 

Interested  consumers,  or  end-users,  will  read  the  “consumer  reports”^^  review  on 
available  applieations,  try  the  applications  out,  and  be  able  to  make  an  informed  deeision 
on  the  purchase  or  aequisition  of  the  system,  component,  or  application. 

The  following  sub-section  presents  an  example  of  a  suceessful  development 
environment  used  in  the  commereial  seetor. 

a.  eBay  Development  Web  Site 

The  eBay  development  eenter  is  a  perfect  example  of  the  NCAP  in  use  in 
the  private  sector.  The  eBay  development  site  allows  developers  to  use  different 
development  environments to  build  applications  that  meet  eertain  eBay  specific 
application  improvement  requirements^^.  The  user  agreements  for  interface, 
eompatibility,  seeurity,  and  coding  are  made  available  to  the  developers — the  KPPs  are 
clearly  spelled  out.  The  developers  ereate  an  applieation  that  is  evaluated  for 

Application  programming  interface  (API)  is  an  interface  in  computer  science  that  defines  the  ways 
by  which  an  application  program  may  request  services  from  libraries  and/or  operating  systems.  [59]. 

Testing  refers  to  any  developmental  testing  and  evaluation  (DT&E)  and  operational  testing  and 
evaluation  (OT&E)  that  is  conducted. 

This  would  be  a  DoD  web  version  of  the  Consumer  Reports  magazine  published  monthly  by 
Consumers  Union.  It  publishes  reviews  and  comparisons  of  consumer  products  and  services  based  on 
reporting  and  results  from  its  in-house  testing  laboratory  [60]. 

eBay  calls  the  development  environments  “development  centers,”  but  there  are  four  environments 
that  a  developer  can  use  to  create  eBay  applications  (JavaScript,  Flash,  PHP,  Windows,  and  Java). 

By  requirements,  eBay  has  many  applications  that  run  on  its  web  site.  Developers  are  given  the 
choice  to  improve  any  of  the  many  applications  (selling,  buying,  listing  products,  etc.)  that  run  on  eBay. 
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compatibility  and  interface  requirements,  tested,  and  V&V.  The  applieation  is  then  made 
available  to  eBay  users  to  test  and  rate  the  applieation  and  then  ean  either  purehase  it  or 
use  it.  If  the  applieation  is  desirable  to  the  end-users,  it  provides  value  and  has  the 
“ilities”^^  that  end-users  desire.  There  is  a  type  of  “eonsumer  reports”  available  to  the 
eonsumers  that  rates  the  different  applieations  (on  a  seale  of  zero  to  five  stars)  and  makes 
the  purehase  or  use  of  an  eBay  developer  eenter  applieation  mueh  easier. 

The  next  part  of  the  NCAP  framework  diseussed  is  the  data  repository. 

3.  Data  Repository 

An  important  part  of  the  NCAP  is  the  use  of  a  data  repository  of  software,  data, 
systems,  sub-systems,  applieations,  and  eomponents.  The  data  repository  would  be  an 
open  souree  “virtual  library”  where  vetted  developers  would  go  and  pull  items 
(eomponent  design,  software,  programming  objeets,  ete.)  and  use  the  pulled  items  in 
developing  systems,  subsystems,  or  applieations  that  meet  eurrent  identified  eapability 
gaps.  The  data  repository  ean  be  seen  in  the  top-down  part  of  the  NCAP  framework  of 
Figure  27. 

The  data  repository  would  ideally  eontain  information  on  all  DoD  systems  and 
sub-systems,  with  the  data  arranged  in  an  easily  searehable  semantie  and  function  based 
format.  The  data  repository  would  have  an  advaneed  semantie  seareh  system  that  would 
faeilitate  seareh  for  items  to  be  reused,  or  modified. 

One  eaveat  about  the  data  repository  is  that  the  DoD  generally  does  not  own 
unlimited  data  rights,  or  government  purpose  rights  (GPR),  to  the  COTS  items  it 
purehases.  In  order  to  be  able  to  make  COTS  items  available  as  “open  souree”  speeial 
eontraets  would  need  to  be  erafted  for  that  purpose  when  and  if  potential  return  on 
investment  warrants.  However,  by  definition,  “COTS”  means  out-of-the-box 
interoperability  aeross  eommereial  standards.  Henee,  it  is  elear  that  entering  COTS 

“ilities”  refers  to  availability,  reliability,  usability,  portability,  ete.  Referenee  [61]  has  a  full  list  of 
system  quality  attributes. 

Vetted  developers  refers  to  DoD  and  private  seetor  personnel  who  understand  the  development 
standards  (interoperability,  seeurity,  ete.)  of  the  NCAP  and  who  have  developed  a  trust  relationship  with 
the  DoD. 


81 


component  information  into  the  data  repository,  regardless  of  the  lieensing  rights,  would 
provide  some  utility  to  developers.  GPR  will  be  diseussed  in  a  later  sub-seetion  of  this 
ehapter. 

One  proponent  of  the  NCAP,  Dr.  Bob  LeFande,  suggested  that  the  use  of  data 
repositories  is  how  modem  industries  aequire  their  produets.  He  stresses  that  the  U.S. 
Government,  the  DoD,  should  always  own  the  design  data  and  software,  with  all 
applieable  lieensing  rights,  and  therefore  be  made  available  to  be  reused,  shared,  and 
improved  by  all  stakeholders  [62]. 

If  the  data  repository  is  eorreetly  set  up,  with  a  detailed  list  of  available  items  to 
reuse,  and  with  an  effieient  seareh  engine,  then  the  data  repository  would  provide  VIRT 
to  the  developers  using  the  repository.  In  other  words,  the  same  information  proeessing 
methods  that  support  NCW  support  network  eentrie  engineering.  By  having  a  well- 
organized  data  repository  with  a  seareh  eapability,  the  developer  would  be  able  to  find 
eomponents  to  reuse  quiekly  (i.e.,  a  high  Aiv). 

Otherwise,  a  poorly  eatalogued  data  repository  with  a  medioere  seareh  engine 
would  require  the  developer  to  spend  more  time  proeessing  data  and  trying  to  figure  out 
what  items  to  reuse.  If  the  effort  to  find  reuse  items  is  too  large,  then  the  developer  eould 
ehoose  to  ereate  their  own  item,  foregoing  the  idea  of  reuse.  Therefore,  it  is  eritieal  to  be 
able  to  effieiently  seareh  and  find  reuse  eomponents.  VIRT  explains  this  in  the  next  sub- 
seetion. 


a.  Valued  Information  at  the  Right  Time 

As  already  diseussed  in  Chapter  II,  VIRT  is  a  generie  solution  to  the 
problem  of  how  to  assure  that  important  information  is  passed  along  and  unimportant 
data  is  not  [26]. 

Although  VIRT  was  earlier  used  to  deseribe  the  effeetiveness  of  NCS,  it 
ean  be  abstraeted  to  measure  the  ability  of  the  NCAP’s  data  repository  to  deliver  valued 
information  to  developers  of  NCS.  Aehieving  VIRT  from  the  data  repository  will  require 
eareful  eataloguing,  frequent  updating,  and  detailed  deseriptions  (semantie  and  ontologie) 
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of  items  entered  into  the  data  repository.  In  addition,  for  high-level  cataloguing,  the  data 
repository  could  be  organized  by  categories,  similar  to  Communities  Of  Interest  (COI),  as 
in  the  Defense  Information  Security  Agency’s  (DISA)  Netcentric  Enterprise  Services 
(NCES)  [63], 

What  follows  is  an  example  of  a  data  repository  that  was  created,  and 
provided  VIRT  to  its  users. 

b.  SHARE  a  Prototype  Data  Repository 

In  2006,  the  DoD,  under  the  guidance  of  Program  Executive  Officer  of 
Integrated  Warfare  Systems  (PEO-IWS),  established  an  ontology^*’  based  software 
repository  called  the  Software  Hardware  Asset  Reuse  Enterprise  (SHARE)  that  facilitated 
the  reuse  of  combat  system  software  and  related  assets  [64].  The  framework  of  the 
repository  used  two  “search”  processes  consisting  of  a  component  specification  search 
(based  on  descriptive  entries)  and  ontology  search  (based  on  a  conceptual  search  and  its 
relationship  to  other  components). 

The  component  specification  search  database  catalogued  the  description  of 
the  items  in  the  repository,  both  metadata^ i  and  software  behavior  descriptions.  The 
metadata  provided  specific  information  on  how  to  use  the  software  item,  while  the 
software  behavior  component  specification  complemented  the  metadata  search 
shortcomings  by  giving  behavioral  data  of  the  software  objects  [64]. 

The  ontology  search  process  included  descriptions  of  the  component’s 
operational  relationship  that  created  different  perspectives,  or  contexts,  for  examining  the 
contents  of  the  repository.  The  relationships  often  include  the  component’s  use  in  the 
existing  system  and  how  it  mapped  to  the  general  system  architecture  [64]. 


Ontology,  in  the  IT  world,  is  a  formal  representation  of  a  set  of  eoneepts  within  a  domain  and  the 
relationships  between  those  eoneepts.  Ontology  is  used  to  reason  about  the  properties  of  that  domain,  and 
may  be  used  to  define  the  domain  [64]. 

Metadata  is  "data  about  other  data,”  of  any  sort  in  any  media.  Metadata  may  inelude  descriptive 
information  about  the  context,  quality  and  condition,  or  characteristics  of  the  data  [64]. 
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The  authors  of  Ontology-based  Solutions  for  Software  Reuse,  stated  that: 


This  enriehed  semantie  [or  deseriptive]  speeifioation  of  the  assets  in  the 
SHARE  repository  will  enable  users  to  more  readily  find  resourees  that 
meet  their  needs  in  their  context.  [64] 

The  reason  for  creating  a  data  repository  is  to  facilitate  VIRT  for  the  reuse 
of  components  by  network-centric  developers. 

The  ideal  NCAP  data  repository  would  be  a  grander  instantiation  of  the  SHARE 
repository  that  would  include  ontology  for  all  DoD  systems  and  include  software, 
hardware,  parts,  architecture  details,  and  drawings.  The  ideal  data  repository  would  be 
very  onerous  to  create,  difficult  to  maintain  current,  and  costly  to  achieve. 

c.  Data  Repository  Way  Ahead 

In  order  for  NCAP  to  begin  making  data  repositories  available,  a  prototype 
data  repository  model  will  have  to  be  created,  modeled  on  and  use  the  SHARE  repository 
data.  As  the  NCAP  is  incrementally  implemented  throughout  the  DoD,  the  data 
repository  would  grow  as  NCS  objects,  elements,  and  software  code  would  be  carefully 

catalogued  into  the  data  repository^^ 

It  will  take  time  to  carefully  and  methodically  catalogue  and  enter  NCS 
objects  into  the  data  repository.  A  standardized  procedure  for  cataloguing  and  verifying 
the  accuracy  of  entries  will  need  to  be  developed,  by  network-centric  acquisition 
stakeholders,  and  articulated  to  the  network-centric  acquisition  community. 

An  incremental  and  iterative  approach  to  updating  and  using  the  data 
repository,  should  be  used,  beginning  with  the  cataloging  of  targeted  NCS,  and  then 
adding  systems  that  will  use  the  NCAP.  Once  the  data  repository  is  able  to  provide 
robust  search  and  discovery  capabilities,  then  a  mass  effort  can  be  undertaken  to 
catalogue  all  DoD  NCS.  The  data  repository  will  continue  to  grow  as  more  NCS  are 
developed  using  the  NCAP. 


C4ISR  legacy  equipment  and  other  network-centric  software  equipment  will  eventually  be  uploaded 
into  the  data  repository,  but  this  will  not  be  an  NCAP  implementation  priority. 
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The  next  seetion  will  present  the  eleetronie  business  (e-Biz)  Marketplaee. 
The  NCAP  proeess  needs  an  environment  where  eonsumers  and  developers  can  be 
matched  in  order  to  facilitate  the  acquisition,  product  reviewing,  and  capability-needs 
determination  Although  the  e-Biz  marketplace  encompasses  and  uses  many  of  the  NCAP 
framework  items  discussed  in  this  section,  it  needs  to  be  discussed  separately  in  order  to 
fully  understand  its  impact  on  the  NCAP. 

4,  Electronic  Business  (e-Biz)  Marketplace 

A  thriving  market  is  a  place  where  providers  and  consumers  can  effectively  find 
each  other,  form  mutually  beneficial  relationships,  and  close  mutually  lucrative 
transactions.  The  DoD  needs  a  new  environment,  call  it  an  electronic  business  (e-Biz) 
marketplace,  where  developers  and  consumers  can  come  together  for  the  purpose  of 
acquiring  and  developing  network-centric  capabilities.  The  e-Biz  marketplace  can  be 
seen  in  the  top-down  part  of  the  NCAP  framework  of  Figure  27. 

Chris  Gunderson,  a  SME  on  network-centric  acquisition,  stated  that: 

What’s  needed  is  a  net-ready  market  for  continuously  improving 
capabilities  for  sharing  information  and  making  better  decisions  more 
rapidly.  In  other  words,  we  need  an  e-market  approach  to  evaluate  and 
build  network  architecture  a  little  bit  at  a  time  [5]. 

For  consumers  of  network-centric  capabilities,  the  e-Biz  marketplace  would  be  a 
venue  where  they  would  be  able  to  search  and  acquire  network-centric  products  that  meet 
their  needs.  If  the  network-centric  capabilities  do  not  yet  exist,  then  the  e-Biz 
marketplace  would  match  consumer’s  needs  with  developers  willing  to  produce  a 
materiel  solution  to  meet  their  need. 

For  developers  of  network-centric  capabilities,  the  e-Biz  marketplace  would  be 
venue  where  they  would  make  their  network-centric  products  available  for  acquisition  by 
consumers.  Developers  would  also  be  able  to  efficiently  develop  NCS  for  consumers  by 
leveraging  the  utilization  of  open  source  equipment/software  found  in  the  network-centric 
data  repository  and  by  using  the  open  and  collaborative  development  environment  of  the 
NCAP. 
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Specifically,  the  e-Biz  marketplace  would  facilitate  the  following: 

•  Finding  providers  of  the  needed  capability,  fellow  consumers  with  similar 
requirements,  consumers  for  the  products  being  offered,  and/or  partners 
who’s  offerings  compliment  your  own — i.e.,  a  dating  service  (to  be 
discussed  later  in  this  sub-section) 

•  An  experimental  venue  for  invention,  bundling,  T&E  and  V&V  of 
potentially  useful  capabilities — e.g.,  SourceForge.net  ,  Java.net^3^  and 
Forge.mil®"^ 

•  A  method  for  evaluating  various  mature  product  offerings  against  each 
other  with  respect  to  important  considerations-  i.e.  consumer  reports 

•  A  means  to  rapidly  close  transactions,  transfer  funds,  and  receive 
capability — e.g.,  Amazon.com,  in  addition  Existing  contract  vehicles 

An  e-Biz  marketplace  portal  supporting  NCAP  would  provide  a  great  service  to  a 
global  community  of  distributed^^  developers  and  consumers  of  network-centric 
processing  capability.  The  e-Biz  marketplace  would  be  an  open  source  and  open 
standards  capability  development  arena  where  developers  and  consumers  are  matched, 
new  capabilities  are  evaluated  and  rated,  and  where  acquisition  transactions  can  occur. 

The  following  subsections  present  specific  details  of  the  e-Biz  marketplace. 
a.  e-Biz  Marketplace  R ales 

NCAP  stakeholders  will  need  to  develop  e-Biz  marketplace  operation, 
development,  and  security  regulations  so  that  all  marketplace  users  know  and  are  able  to 
safely  and  confidently  utilize  the  e-Biz  marketplace. 

The  regulations  governing  the  operation  of  the  e-Biz  marketplace  would 
complement  the  ones  created  for  the  NCAP  data  repository.  The  e-Biz  governing 


SourceForge.net  and  Java.net  are  open  source  software  development  sites  used  for  innovative 
development. 

Forge.mil  is  a  family  of  services  provided  to  support  the  DoD's  technology  development 
community.  The  system  currently  enables  the  collaborative  development  and  use  of  open  source  and  DoD 
community  source  software. 

Distributed  refers  to  the  ability  to  be  distributed  geographically  throughout  the  globe,  but  connected 
via  the  NCAP  framework. 
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regulations  would  also  include  guidance  on  how  the  acquisition  contracting  vehicles 
would  operate  and  incorporate  best  business  practices  from  the  private  commercial 
sector. 


b.  Matching  Consumers  and  Developer — A  Dating  Service 

The  e-Biz  marketplace  would  provide  a  service  that  would  bring 
developers  and  consumers  together.  All  users  of  the  NCAP  would  create  profiles  in  the 
e-Biz  marketplace  domain,  and  either  enter  their  network-centric  requirements^^  or  their 
capabilities  that  are  available  for  acquisition,  into  their  profile.  Developers  would  browse 
a  list  of  unfulfilled  network-centric  requirements  and  choose  a  requirement  to  develop. 
Customers  would  browse  a  list  of  available  network-centric  capabilities,  and  ideally  find 
the  capability  that  meets  their  need,  helping  implement  VIRT  into  the  e-Biz  marketplace. 

Although  the  framework  for  the  “dating  service”  is  not  detailed,  and  only 
presented  with  great  abstraction,  the  desired  outcome  is  to  have  a  method  for  matching 
consumers  and  developers  in  an  efficient  and  timely  manner. 

c.  Vetted  Developers 

In  order  to  make  the  e-Biz  marketplace  work  effectively,  developers 
would  need  to  pass  through  a  “vetting  process”  that  would  certify  their  ability  to  comply 
with  the  development  rules  and  regulations  of  the  e-Biz  marketplace.  The  vetting  process 
would,  in  essence,  be  a  screening  to  ensure  that  the  products  developed  were  compliant 
with  DoD  development  standards  (e.g.,  ISO,  lA,  Security,  etc.). 

Vetting  developers  helps  ensure  that  they  are  using  industry  best  industry 
practices  and  maximize  the  lA  compliance  (confidentiality,  integrity,  and  availability)  of 
the  developed  system. 


Network-centric  requirements,  in  this  context,  refers  to  the  capabilities  that  the  customer  or  end-user 
is  looking  to  acquire. 
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Although  this  section  only  gives  high  level  vetting  criteria  for  developers, 
the  vetting  process  would  ultimately  ensure  that  only  trusted  developers  are  allowed  into 
the  e-Biz  marketplace.  Therefore,  developers  wanting  to  participate  in  the  NCAP  would 
have  to  be  “certified”  (vetted)  to  become  vehed  developers. 

d.  Financial  Transactions 

Although  not  discussed  in  this  thesis,  a  series  of  contract  vehicles  will 
need  to  be  developed  in  order  to  correctly  incentivize  developers  to  participate  in  the  e- 
Biz  marketplace,  and  therefore  in  the  NCAP.  The  contracting  vehicles  need  to  be  devised 
in  a  way  that  they  are  flexible  enough  to  support  the  agile  NCAP. 

5.  Value  off-the-Shelf 

Value-Off-The-Shelf  (VOTS)  is  an  important  part  of  the  NCAP.  OTS^^  products 
provide  an  affordable  way  to  acquire  needed  capabilities  with  virtually  no  development 
time  (they  are  already  available  and  on-the-shelf),  and  are  easy  to  use  (plug  and  play), 
requiring  little  personnel  training.  OTS  can  be  seen  in  the  bottom-up  (for  GOTS)  and 
disadvantaged  user  (COTS)  parts  of  Figure  27. 

VOTS  is  defined  as  follows: 

[an]  approach  at  delivering  “good  enough”  ^8  capability  fast  enough  to  take 
advantage  of  the  rapid  advances  taking  place  in  the  information 
technology  market.  This  approach  emphasizes  reusing  and  bundling 
interoperable  [OTS]  components  in  an  architecture  optimized  for  Trusted 
VIRT.  [5] 


OTS  should  be  thought  of  as  a  product  that  is  available  commercially.  It  is  “shrink-wrapped”  in  a 
package  and  is  ready  for  use  once  it  is  out  of  the  box. 

^8  Good  enough  capability  refers  to  the  decision  to  field  a  network-centric  system  quickly,  and  by 
doing  so,  the  PM  is  accepting  a  product  that  does  not  have  all  the  desired  capabilities,  but  good  enough 
capabilities  to  perform  the  intended  mission.  Future  upgrade  or  refresh  cycles  will  be  needed  to  deliver  all 
the  desired  capabilities. 
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OTS  consists  of  COTS  and  GOTS^^  argument  for  favoring  a  VOTS 

delivery  proeess  eomes  from  the  ability  of  OTS  produets  to  reduee  the  time  and  eost  of 
implementing  eapability  improvements.  OTS  leverages  existing  teehnology,  whieh  is  not 
the  same  thing  as  reuse,  and  gives  end-user  a  eapability  as  soon  as  the  system  is  set-up 
[5], 

It  is  important  to  understand  that  when  OTS  items  are  entered  into  the  data 
repository  (ontology  and  semantie  seareh  parameters  and  uploaded  applieable  software 
and  eode)  the  item  beeomes  GFE.  There  will  be  lieensing  issues  with  making  OTS  items 
GTE,  with  open  source  and  open  lieenses  that  allow  vetted  developers  to  use  and  modify 
those  items.  The  licensing  issues  are  beyond  the  scope  of  this  thesis,  and  will  not  be 
addressed. 

Eigure  27  shows  how  OTS  is  the  disadvantaged  user  of  the  NCSE  eore  diagram 
beeause  it  laeks  the  required  seeurity  and  intereonnectivity,  but  onee  entered  into  the  data 
repository  (as  GEE)  it  becomes  part  of  the  top-down  approach.  Conversely,  GOES  is  part 
of  the  bottom-up  approaeh  and  ean  be  uploaded  to  the  data  repository,  but  GOTS  belongs 
in  the  disadvantaged  user  approaeh  if  it  does  not  have  the  right  legal  interfaees  to  allow 
developers  to  modify  and  innovate  with  it  (e.g.,  upload  to  the  database  repository). 

a.  Reuse  Components  versus  Off-the-Shelf 

The  foeus  of  the  NCAP  is  to  deliver  “better”  speed- to-capability  and 
“better”  speed-to-better-eapability.  The  framework  of  NCAP  advoeates  both  the  reuse  of 
eomponents  and  maximizing  the  use  of  OTS.  When  NCAP  stakeholders  are  presented 
with  a  deeision  to  aequire  OTS  eomponents,  or  reuse  existing  eomponents,  the  metrics 
(Anr  and  Aiv)  should  be  used  to  determine  what  approaeh  to  take. 


GOTS  is  a  term  used  for  software  and  hardware  produets  that  are  either  developed  by  U.S. 
Government  ageneies  or  by  an  external  entity,  but  with  funding  and  speeifieation  from  the  government  end- 
user.  GOTS  software  solutions  ean  be  shared  amongst  U.S.  Government  ageneies  without  additional  eost 
165]. 
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It  is  possible  that  the  data  repository  will  have  COTS/GOTS,  and  they  will 
be  ealled  GFE  produets  in  its  database.  Semantieally  it  eould  be  argued  that  it  is  reuse  of 
a  eomponent  viee  OTS,  but  the  real  issue  is  that  the  developer  reeeived  VIRT  (through 
the  use  of  the  data  repository)  that  helped  in  the  development  of  a  network-eentrie 
produet. 


b.  Commercial  and  Government  Off-the-Shelf 

Using  OTS  produets  is  advantageous  to  the  DoD  beeause,  generally,  OTS 
produets  are  eheaper  to  aequire  and  do  not  require  development  time.  There  is  time  to 
adapt  and  integrate  the  eomponents  into  the  overall  system.  Thus  with  OTS,  the  speed- 
to-eapability  foeus  of  NCAP  is  maintained. 

In  NCAP,  the  new  paradigm  will  be  for  PMs  to  “buy  down  risk”  to  cost, 
performance,  and  schedule  by  consuming  as  much  pure  COTS  or  GOTS  as  possible.  The 
PM  will  then  document  the  gap  between  COTS/GOTS  capability  and  total  system 
requirement  and  invest  his  new  development  effort  to  close  the  gap.  Of  course  when  the 
PM  does  that,  he  should  be  sure  to  use  a  license  model  that  clearly  emphasizes 
government  purpose  rights  for  re-use. 

c.  Information  Assurance  in  Off-the-Shelf  Products 

A  gap  between  military  requirements  and  COTS  IT  products  will  often 
concern  the  lA  requirements.  Typically  COTS  products  are  not  especially  secure. 
Therefore,  DOD  will  need  to  invest  in  developing  lA  solutions  that  COTS  vendors  can 
easily  bundle  in  their  future  offerings  (this  is  the  interface  with  the  disadvantaged  user  in 
Figure  27). 

A  solution  for  the  lA  issues  of  OTS  is  not  addressed  in  this  thesis,  but 
network-centric  acquisition  stakeholders  will  be  able  to  use  the  metrics,  presented  earlier 
in  this  chapter,  to  determine  if  an  OTS  acquisition  will  be  able  to  deliver  the  required 
capabilities,  or  if  a  solution  using  reused  components  delivers  better  speed-to-capability 
and  better  speed-to-better-capability. 
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In  this  and  the  previous  sections,  the  concepts  of  software  reuse,  a  data 
repository,  and  OTS  are  discussed.  The  next  section  discusses  open  systems,  licensing 
rights,  and  Government  Purpose  Rights  (GPR),  which  are  important  in  continuing  to  be 
able  to  develop  NCS  that  are  delivered  quickly  and  at  a  reasonable  cost.  Open  systems 
and  GPR  are  important  in  the  NCAP  framework  because  if  innovation  is  expected  to 
flourish,  then  developers  will  need  to  use  open  systems  that  have  open  source  items  to 
foster  that  innovation. 

6,  Open  Systems  and  Government  Purpose  Rights 

The  DoD  has  been  pushing  open  system  implementation  since  1994  [66].  The 
Defense  Acquisition  University  (DAU)  Continuous  Learning  (CL)  Module  Modular 
Open  Systems  Approach  to  DoD  Acquisition  (CLE  013)  defines  an  open  system  as 
follows: 

[An  open  system]  employs  modular  design,  uses  widely  supported  and 
consensus-based  standards  for  its  key  interfaces,  and  has  been  subjected  to 
successful  validation  and  verification  tests  to  ensure  the  openness  of  its 
key  interfaces.  [67] 

Open  systems,  although  not  shown  in  Figure  27,  are  enablers  that  allow  for  the 
integration  of  the  top-down,  middle,  bottom-up  and  disadvantaged  user  parts  of  the 
NCAP  framework. 
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DOD  Framework 

Type  of  Data  Rights 

Definition 

Applies  to 

Unlimited  Rights 

Right  to  use  and  disclose 
the  data  publicly,  in  any 
manner  and  for  any  purpose 
and  to  permit  others  to  do 
so. 

Data  created  exclusively 
with  government  funds 
and  certain  types  of  other 
data  delivered  to  the 
government  regardless  of 
funding. 

Government  Purpose  Rights 

Right  to  use  or  disclose 
within  the  government 
without  restriction  or 
disclose  to  third  parties  for 
government  purposes  only. 
Third  parties  cannot  use  the 
data  for  commercial 
purposes. 

Data  developed  with  a  mix 
of  government  and  private 
funds. 

Limited  Rights 

Right  to  use  or  disclose  data 
internally.  No  disclosure  to 
third  parties  without  written 
permission  except  under 
limited  conditions  (e.g., 
emergency  repair) 

Data  pertaining  to  items, 
components,  or  processes 
developed  at  private 
expense. 

Figure  30.  Data  rights  in  the  Department  of  Defense  Aequisition  Framework  (From  [68]) 


Network-centric  acquisition  expects  systems  to  be  “open’’^^  and  that  the  DoD 
have  “unlimited”  purpose  rights^i,  given  to  the  DoD  as  part  of  the  acquisition  contract. 
The  purpose  right  applies  mostly  to  the  technical  data  and  computer  software,  but  could 
also  apply  to  hardware  designs.  Figure  30  shows  the  different  technical  data  rights  that 
are  seen  in  the  DoD  acquisition  contracts. 

A  promising  approach  for  DoD  to  manage  its  GPR  is  by  specifying  in  acquisition 
contracts  that  it  desires  a  GPR  license.  According  to  G.  Tereschuk,  a  Patent  Attorney 
with  the  U.S.  Army  Communications/Electronics  Life-Cycle  Management  Command 
(CE/LCMC),  a  GPR  is: 

an  Intellectual  Property  licensing  system  that  is  available  to  DOD 
acquisitions.  [GPR]  lies  somewhere  between  the  broad  Unlimited  Rights 
license  rights  allowing  unrestricted  Government  release  of  information 

Open  refers  to  all  of  the  following:  open  arehiteeture  (whieh  allows  all  to  see  inside  all  or  parts  of 
the  arehiteeture  without  any  proprietary  eonstraints),  open  system,  and  open  souree  (souree  eode  available 
to  the  general  publie  with  relaxed  or  non-existent  eopyright  restrietions).  When  items  are  “open” 
developers  ean  reuse  and  alter  the  item  with  little  or  no  lieensing  restrietions  [66]. 

Government  ean  not  hold  unlimited  lieense  rights.  Commereial  developers  always  retain  some 
ownership  of  IP  they  develop. 
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and  the  more  restrietive  Limited  or  Restricted  Rights  licensing  rights  that 
forbid  most  releases  outside  the  Government.  The  [GPR]  license  affords 
the  Government  with  a  comprehensive  set  of  non-commercial  license 
rights  blending  the  broad  Unlimited  Rights  and  more  restrictive  Limited  or 
Restrictive  Rights  license  terms.  [69] 

One  great  advantage  of  GPR  is  that  it  can  enforce  an  open  modular  design  via 
making  GOTS  available  to  developers  and  GFE^^ 

According  to  the  Defense  Federal  Acquisition  Regulation  Supplement  (DFARS) 
Section  252.227-7103: 

[GPR]  means  the  rights  to — 

Use,  modify,  reproduce,  release,  perform,  display,  or  disclose  technical 
data  within  the  Government  without  restriction;  and  (ii)  Release  or 
disclose  technical  data  outside  the  Government  and  authorize  persons  to 
whom  release  or  disclosure  has  been  made  to  use,  modify,  reproduce, 
release,  perform,  display,  or  disclose  that  data  for  United  States 
government  purposes.  [54] 

Acquiring  a  GPR,  by  the  DoD,  for  acquired  items,  ensures  that  the  DoD  will  not 
be  held  “hostage”^^  to  the  system  designer  for  the  life  cycle  of  the  system  and  that  future 
iterations  of  the  system  can  be  worked  on  in  an  open,  collaborative  and  competitive 
environment  that  fosters  innovation. 

7.  Certification  and  Information  Assurance  of  Network-Centric 
Products 

lA  concerns  are  not  specifically  addressed  in  this  thesis,  thus  it  is  important  to 
state  that  under  the  NCAP,  guidelines  for  component  certification  and  lA  will  need  to  be 
developed  by  NCAP  stakeholders.  These  guidelines  will  need  to  be  clearly  understood 
by  developers  and  effectively  communicated  to  all  network-centric  acquisition 
stakeholders.  This  will  ensure  that  developers  are  able  to  produce  systems  that  meet 


The  data  repository  would  make  GFE  available  to  the  developers  for  their  use  and  integration  into 

NCS. 

Hostage  refers  to  possible  high  costs  paid  by  the  DoD  to  change  systems  for  which  it  does  not  own 
the  licensing  right.  Effectively  being  held  hostage  by  the  license  rights  owner. 
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certification  and  I A  requirements  for  those  systems.  Certification  and  I A  integrate  the 
top-down,  bottom-up,  middle  approach,  and  disadvantaged  user  to  the  NCSE  core  (the 
trunk)  of  the  NCAP  framework  (Figure  27). 

8,  Relating  NCAP  Framework 

The  NCAP  framework,  as  related  to  the  NCSE  core  (Figure  27),  is  made  of 
several  systems  and  approaches  (e.g.,  processes)  that  overlap  and  integrate  in  order  to 
operate  effectively.  For  example,  a  critical  process  is  the  need  to  reuse  components 
(components  are  the  network-centric  applications  in  the  bottom-up  approach  and  the 
components  from  the  data  repository  in  the  top-down  approach  of  Figure  27).  In  order  to 
reuse  components  and  innovate,  a  collaborative  development  environment  is  needed 
where  the  reused  components  can  be  modified,  tested,  and  if  needed  integrated  into  new 
systems.  The  data  repository  is  another  core  part  of  NCAP  (part  of  the  top-down 
approach  of  Figure  27)  that  has  the  components  that  can  be  reused.  In  addition  to  the 
data  repository,  the  e-Biz  marketplace  provides  a  marketplace  (for  sale  of  network-centric 
applications)  and  dating  service  (to  match  customers  and  developers);  this  is  part  of  the 
top-down  approach  of  Figure  27.  Components  can  also  be  acquired  through  an  OTS 
process  (disadvantaged  user  in  Figure  27).  The  network-centric  “glue,”  open  systems, 
open  license,  GPR,  certification  and  lA  enable  the  NCAP  and  make  up  the  core  part  of 
Figure  27  that  integrates  all  the  branches. 

The  next  section  of  this  chapter  will  present  the  recommendations  of  a  study  by 
the  DSB  for  the  implementation  of  an  acquisition  model  for  IT  that  will  replace  the  DAS 
model  presented  in  Figure  13  of  Chapter  III.  This  is  being  presented  as  a  foundation  for 
NCAP  and  DoD  Directive  5000.01  recommendations. 

F.  ACQUISITION  MODEL  FOR  NETWORK-CENTRIC  SYSTEMS 

The  NCAP  is  a  SE  based  process  that  can  be  used  to  develop  network-centric 
components.  Chapter  III  discussed  DoD  acquisition,  and  presented  in  detail  the  Fittle  “a” 
acquisition  process,  see  Figure  9. 
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The  framework  for  NCAP  gives  a  “close-in”  view  of  how  network-centric 
acquisition  will  work.  Stepping  back  and  looking  at  the  NCAP  at  the  DAS  level,  it  is 
clear  to  see  that  the  current  iteration  of  the  DAS  (Figure  13)  does  not  support  NCAP. 
The  current  DAS  model  is  slow,  serial  and  designed  to  acquire  large  military  systems. 
The  NCAP  framework  requires  a  fast,  parallel,  and  iterative  approach  to  acquisition. 

A  recent  report  by  the  Defense  Science  Board^^  stated  that: 

The  conventional  DOD  acquisition  process  is  too  long  and  too 

cumbersome  to  fit  the  needs  of  the  many  systems  that  require  continuous 

changes  and  upgrades.  [50] 

In  the  same  report,  the  DSB,  recommended  that  a  new  acquisition  and 
requirements  development  process  for  IT  systems  be  developed.  The  DSB  provided  an 
acquisition  process  that  is  modeled  on  commercial  best  practices  [50].  The  new  IT 
acquisition  process  proposed  by  the  DSB  is  shown  in  Figure  31,  and  can  be  incorporated 
easily  into  the  NCAP  framework  even  though  the  DSB  proposed  model  focuses  on  IT 
acquisition,  while  this  thesis  focuses  on  NCS  acquisition.  The  new  acquisition  process 
fits  the  NCAP  framework  because  they  both  focus  on  fast,  parallel,  and  iterative 
development.  In  addition,  the  NCAP  process  focuses  on  acquiring  the  “glue”  of  network- 
centricity — described  earlier  as  network-centric  IT. 

For  brevity  and  ease  of  use,  the  new  acquisition  and  requirements  development 
process  for  IT  will  henceforth  be  referred  to  as  the  “Network-Centric  System  Acquisition 
Model”  (NCSAM). 

The  following  subsection  describes,  at  a  high  level,  the  operation  of  the 
NCSAM.  75 


74  The  DSB  provides  independent  adviee  and  reeommendations  to  senior  DoD  personnel  on  seientifie, 
teehnieal,  manufaeturing,  aequisition  proeess,  and  other  matters  of  speeial  interest  to  the  DoD 
(http://www.aeq.osd.mil/dsb/eharter.htm). 

75  For  more  detailed  understanding  of  the  NCSAM,  read  Chapter  6  of  the  DSB  report  [50]. 
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Figure  3 1 .  New  Acquisition  and  Requirements  Development  Process  for  IT  Systems  or 
Network-Centric  System  Acquisition  Model  (From  [50]). 


The  NCSAM  is  an  agile  process  that  is  focused  on  delivering  capabilities  in  18- 
month  increments,  and  leverages  the  advantages  of  modem  IT  practices  [50].  NCSAM  is 
divided  into  four  phases  and  each  phase  begins  with  a  decision  point  that  requires  MDA 
approval. 

The  first  two  phases  of  the  NCSAM  the  Business  Case  Analysis  and  Development 
(BCAD)  phase  and  the  Architecture  Development  and  Risk  Reduction  (ADRR)  phase  are 
very  similar  to  the  MSA,  TD,  and  EMD  phases  described  in  Chapter  IIL  The  noticeable 
difference  is  that  the  NCSAM  model  exits  the  Milestone  Build  Decision  (similar  to 
Milestone  B  decision)  with  an  acquisition  strategy  and  acquisition  program  baseline  for  a 
certain  number  of  capability  releases,  and  with  full  funding  for  all  future  releases^®. 

The  next  phase,  the  Development  and  Demonstration  (D&D)  phase  builds  and 
delivers  operational  capability  for  a  set  number  of  releases.  For  each  release,  the  PM 
updates  the  system  design  and  must  receive  MDA  approval  prior  to  beginning  each 
iterative  release.  After  three  iterations  of  a  release  and  a  successful  lOT&E  and  positive 
decision  by  the  MDA^^,  the  system  is  fielded  [50]. 


Full  funding  for  all  releases  means  that  funds  are  appropriated  for  all  approved  iterative  releases  of 
capability,  thus  reducing  the  risk  of  funding  cuts  in  subsequent  budgeting  years. 

The  positive  MDA  decision  is  based  on  meeting  all  the  requirements  for  the  specific  release. 
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Subsequent  releases  will  have  to  again  go  through  an  MDA  deeision  point,  in 
order  to  ensure  that  the  future  releases  are  based  on  mature  technologies,  have  an 
acquisition  strategy  and  baseline  approved  by  the  MDA,  and  remain  fully  funded. 

The  last  phase  is  the  Operations  and  Support  (O&S)  phase  that  is  very  similar  to 
the  OS  phase  described  in  Chapter  III. 

G.  CONCLUSIONS 

The  NCAP,  as  proposed,  would  incorporate  all  that  was  discussed  in  sections  A 
thru  C  of  this  chapter,  and  use  the  acquisition  model  proposed  by  the  DSB  [50]  and 
briefly  described  in  section  D  of  this  chapter.  The  focus  of  the  NCAP  is  to  facilitate  the 
speed-to-capability  and  speed-to-better-capability  of  network-centric  applications  by 
acquiring  the  “glue”  of  network-centricity.  By  favoring  speed-to-capability,  NCS  would 
be  able  to  take  advantage  of  cutting  edge  technology,  because  with  short  development 
and  release  cycles,  the  technology  would  not  be  obsolete  when  it  is  ready  to  be  deployed 
to  the  warfighters. 

In  summary,  the  NCAP 

•  can  be  related  to  the  NCSE  core  tree  diagram 

•  focuses  on  reuse  of  existing  components  that  reduce  acquisition  development 
time 

•  maximizes  the  use  of  collaborative  development  environments  that  advocate 
open  source  and  competition 

•  uses  a  data  repository  used  to  search  for  existing  items  to  reuse 

•  uses  an  e-Biz  marketplace  to  transacts  its  business,  to  match  consumers  and 
developers,  and  review  products 

•  advocates  the  use  of  OTS  products  by  encouraging  PM  to  buy  down  as  much 
capability  risk  with  OTS 

•  provides  open  systems  to  developers  as  GFE  and  maximizes  GPR  in 
contracting  language 

•  uses  regulation  to  facilitate  certification,  V&V,  testing,  and  I A  for  developed 
applications. 
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It  is  important  to  note  that  the  NCAP  is  network-eentric  and  faeilitates  network- 
centrie  “business”  operations.  The  NCAP  framework  ean  be  mapped  back  to  the  central 
tenets  of  NCW,  discussed  in  Chapter  II,  to  show  its  network-centric  nature.  Figure  32  is 
a  visual  description  of  NCW,  where  the  info-structure  supports  a  series  of  concentric 
rings  of  network-centric  capabilities  that  ultimately  support  full  spectrum  dominance. 


Figure  32.  Network-Centric  Warfare  Framework  (From  [70]) 


The  reuse  of  components  facilitates  product  development  and  is  analogous  to 
“speed  of  command”  in  Figure  32.  The  collaborative  development  environment  is 
analogous  to  the  “info-structure”  and  “shared  battlespace  awareness”  of  Figure  32.  The 
data  repository  is  analogous  to  the  “information  superiority”  of  Figure  32.  The  e-Biz 
marketplace  is  analogous  to  the  “shared  battlespace  awareness”  and  “shared 
commander’s  intent”  of  Figure  32.  The  use  of  OTS,  GFE,  and  open  systems  is  analogous 
to  “speed  of  command”  of  Figure  32.  The  NCAP  regulations  for  certification,  V&V, 
testing,  and  lA  are  analogous  to  “shared  commander’s  intent”  of  Figure  32.  Lastly,  the 
users  of  NCAP  will  have  innovative  products  that  are  analogous  to  “self¬ 
synchronization”  of  Figure  32. 
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The  NCAP,  if  implemented  and  scaled  correctly,  would  deliver  “good  enough” 
capabilities  to  the  end-user  faster,  with  more  frequent  incremental  capability 
improvements,  and  at  a  reduced  cost. 

The  NCAP  should  be  adopted  by  the  DoD  and  used  in  conjunction  with  the  DSB 
proposed  NCSAM.  Using  the  NCAP  in  the  DoD  acquisition  framework  of  the  NCSAM 
would  help  deliver  “better”  speed-to-capability  and  “better”  speed-to-better-capability. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  THESIS  OVERVIEW 

This  thesis  has  covered  a  wide  swath  of  information  from  the  network-centric 
world,  and  has  applied  it  to  a  narrow  part  of  network-centric  acquisition,  specifically 
introducing  and  detailing  the  Network-Centric  Acquisition  Process  (NCAP). 

The  chapters  of  this  thesis  were  structured  in  a  manner  that  would  support  the 
presentation  of  the  NCAP.  Chapter  I  provided  an  overview  of  the  thesis,  discussed  the 
underlying  reasons  for  developing  the  NCAP,  and  the  expected  benefits  of  the  study. 
Chapter  II  gave  an  overview  of  network-centricity,  describing  its  origins,  the  underlying 
theory,  and  defining  what  a  Network-Centric  System  (NCS)  is.  Chapter  III  gave  an 
overview  of  Defense  Acquisition  and  described  in  detail  its  different  parts  (PPBES, 
JCIDS,  and  the  DAS).  Chapter  IV  presented  several  different  SE  approaches,  described 
in  detail  a  generic  SE  approach  to  acquisition,  and  mapped  the  generic  SE  approach  to 
acquisition  to  the  DoD  acquisition  process.  Based  on  the  foundations  of  Chapters  I-IV, 
Chapter  V  presented  the  NCAP  and  a  detailed  explanation  of  its  framework.  This 
Chapter  gives  conclusions  and  recommendations. 

B,  CONCLUSIONS 

In  order  to  correctly  enable  Network-Centric  Warfare  (NCW),  the  DoD  needs  to 
acquire  NCS  that  continue  to  provide  “better”  speed-to-capability  but  “better”  speed-to- 
better-capability.  NCS  are  very  diverse  and  can  range  from  a  large  ship,  to  a  small 
unmanned  aerial  vehicle,  but  the  common  thread  that  makes  them  network-centric  is  their 
ability  to  harness  the  power  of  the  network  to  gain  information  and  decision  superiority 
over  an  adversary.  What  allows  NCS  to  harness  the  power  of  the  network  is  the 
backbone  of  Information  Technology  (IT)  software.  The  NCAP  provides  an  efficient  and 
effective  way  to  acquire  the  IT  software  backbone,  or  network-centric  “glue,”  that 
enables  network-centricity. 
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The  current  DoD  acquisition  system  is  slow,  serial  in  nature,  delivers  large 
“chunks”  of  capability  at  once,  is  expensive,  has  slow  refresh  cycles,  and  encourages 
stovepiped  processes  and  systems  to  exist.  The  urgency  of  GWOT  makes  it  critical  to 
improve  the  DAS  so  that  it  can  anticipate  threats  and  quickly  respond  to  those  threats  via 
the  fast  development  and  fielding  of  new  capabilities.  The  NCAP  provides  an  alternative 
for  faster  acquisition,  by  focusing  on  delivering  “better”  speed-to-capability  and  “better” 
speed-to-better-capability  while  incorporating  current  DoD  network-centric  guidance  and 
industry  best  practices. 

The  NCAP  framework  incorporates  metrics  that  measure  the  processes’  ability  to 
deliver  “better”  speed-to-capability  and  better  speed-to-“better”-capability.  The 
framework  also  incorporates  industry  best  practices  such  as  component  reuse, 
collaborative  environment,  acquisition  data  repository,  electronic  business  marketplace, 
and  OTS  components. 

The  implementation  of  the  NCAP  will  require  fresh  interpretations  of  DoD 
Directive  5000.01,  the  Federal  Acquisition  Regulations,  and  other  governing  directives. 
The  DSB,  in  one  of  its  2009  reports,  proposed  new  acquisition  and  requirements 
development  process  for  IT  (see  Figure  31)  [50]  and  was  referred  to  in  Chapter  V  as  the 
Network-Centric  System  Acquisition  Model  (NCSAM).  The  NCSAM  will  provide  the 
ideal  framework  on  which  the  NCAP  can  operate  because  it  supports  quick  iterative 
development  cycles  with  frequent  capability  upgrades. 

C.  RECOMMENDATIONS 

The  following  recommendations  are  made  in  order  to  help  improve  DoD 
acquisition  of  NCS. 

1.  Develop  and  Field  Test  the  Network-centric  Acquisition  Process 

The  primary  recommendation  of  this  thesis  is  that  the  NCAP,  whose  framework 
was  presented  in  Chapter  V,  should  be  adopted  by  the  DoD  in  its  acquisition  of  network- 
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centric  capabilities.  The  adoption  of  the  NCAP  should  be  done  in  a  small-scale, 
acquisition  environment,  or  prototype  venue,  and  then  slowly,  and  iteratively,  scaled  to 
larger  acquisitions. 

The  concepts  and  theories  for  the  NCAP  framework  were  taken  from  industry 
best  practices,  but  these  concepts  need  to  be  verified  to  ensure  that  they  work  in  a  DoD 
acquisition  framework.  It  is  recommended  that  the  NCAP  be  used  on  a  small  acquisition, 
be  it  a  test  scenario,  and  then  expanded  if  successful  acquisitions  are  achieved. 

When  implementing  the  NCAP,  it  will  be  important  to  use  the  NCAP  metrics, 
discussed  in  Chapter  V,  that  measure  “better”  speed-to-capability,  Anr,  and  better  speed- 
to-“better”-capability,  Aiv  as  a  means  to  objectively  evaluate  the  acquisition. 

It  is  expected  that  the  NCAP  will  not  be  implemented  with  its  framework  fully 
operational  (i.e.,  data  repository,  e-Biz  marketplace,  or  development  environment 
working),  but  this  should  not  slow  or  halt  the  implementation  of  the  NCAP,  because  it 
will  be  evolutionary.  As  NCAP  framework  items  become  operational,  they  should  be 
incorporated  into  the  operational  version  of  the  NCAP. 

2.  Change  the  Operation  of  the  Defense  Acquisition  System,  DoD 
Directive  5000.01 

DoD  should  implement  the  recommendations  of  the  Defense  Science  Board 
(DSB)  March  2009  report.  Department  of  Defense  Policies  and  Procedures  for  the 
Acquisition  of  Information  Technology  [50],  that  recommended  that  DoD  Directive 
5000.01  use  a  new  acquisition  process  for  IT,  called  NCSAM  framework  in  Chapter  V 
(see  Figure  31). 

By  implementing  the  DSB  recommendations,  the  DoD  will  give  the  NCAP  an 
acquisition  framework  that  will  enable  fast,  iterative,  and  agile  acquisition. 
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3,  Long-term  Development  of  the  Network-Centric  Data  Repository 

The  DoD  should  begin  ereating  a  network-eentric  data  repository  that  mirrors  the 
seareh  and  ontology  struetures  of  the  SHARE  repository,  deseribed  in  Chapter  V  and  in 
Ontology-based  Solutions  for  Software  Reuse  [64],  The  creation  of  the  data  repository 
will  need  to  begin  slowly  and  on  a  small  scale. 

The  creation  of  the  data  repository  will  be  a  challenging  and  difficult  task.  It  will 
require  clear  and  well  thought  out  guidance  on  how  to  enter,  classify,  and  store  repository 
items.  It  is  possible  that  the  network-centric  data  repository  will  not  be  operational  until 
several  iterations,  with  a  prototype  NCAP  data  repository,  are  completed. 

4,  Framework  of  Network-Centric  Collaborative  Development 
Environment 

Further  studies  should  be  conducted  by  the  DoD  to  determine  the  best  framework 
to  use  in  the  network-centric  collaborative  development  environment.  The  framework 
will  include  the  development  environment  to  use,  the  standard  software  interfaces,  the 
minimum  lA  requirements,  and  the  licensing  rights  requirements. 

Forge.mil  should  serve  as  a  model,  prototype,  or  even  as  the  development 
environment  to  be  used  when  implementing  the  early  versions  of  the  NCAP. 

5,  e-Biz  Marketplace  Structure  and  Business  Rules 

Further  studies  should  be  conducted  by  the  DoD  to  determine  the  best  framework 
to  use  in  the  e-Biz  marketplace.  The  requirements  for  the  e-Biz  marketplace  were 
discussed  in  Chapter  V,  but  consultation  and  collaboration  with  e-Biz  marketplace 
industry  leaders  (e.g.,  eBay  and  Amazon)  could  help  create  an  effective  DoD  e-Biz 
marketplace,  or  prototype,  on  which  to  test  the  NCAP. 

6,  Network-centric  Acquisition  Stakeholder  Education  and  Training 

DoD  should  use  the  material  in  this  thesis  and  references  to  create  a  course  that 
would  help  educate  DoD  acquisition  stakeholders  on  network-centricity,  the  DoD 
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acquisition  process,  and  the  NCAP.  The  Naval  Postgraduate  Sehool  eould  plan  on  using 
this  thesis  and  references  for  eourse  material  in  the  Network-Centrie  Systems 
Engineering  eourses. 

This  thesis  has  eovered  a  wide  array  of  information,  starting  with  network- 
eentricity,  to  the  Defense  Aequisition  Proeess,  through  Systems  Engineering,  and  finally 
into  the  NCAP.  The  NCAP  is  a  new  and  revolutionary  proeess  for  aequiring  network- 
eentrie  systems,  but  it  needs  to  be  tested  in  order  to  objectively  know  if  it  will  deliver  on 
its  promises  of  speed-to-eapability  and  speed-to-better-eapability.  What  is  eertain  is  that 
NCAP  is  eritieal  for  network-centrie  warfare  and  network  eentrie  operations  in  this  time 
of  Global  War  on  Terror. 
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APPENDIX:  GENERIC  SYSTEMS  ENGINEERING  APPROACH 


A  review  of  the  SE  proeesses  standard  and  eapability  model,  discussed  in  Chapter 
IV,  Section  C,  shows  that,  although  each  is  essentially  different,  all  are  very  similar 
because  the  general  underlying  process  is  a  common  thread  through  all  of  them.  An 
important  part  of  SE  is  the  use  of  multidisciplinary  Integrated  Product/Project  Teams 
(IPT). 


According  to  the  DoD  Integrated  Product  and  Process  Development  Handbook 
[71],  an  IPT  is: 

a  multidisciplinary  group  of  people,  who  are  collectively  responsible  for 
delivering  a  defined  product  or  process.  The  IPT  is  composed  of  people 
who  plan,  execute,  and  implement  life-cycle  decisions  for  the  system 
being  acquired.  It  includes  empowered  representatives  (stakeholders) 
from  all  of  the  functional  areas  involved  with  the  product — all  who  have  a 
stake  in  the  success  of  the  program,  such  as  design,  manufacturing.  Test 
and  Evaluation  (T&E),  and  logistics  personnel,  and,  especially,  the 
customer.  Because  the  activities  relative  to  a  system’s  acquisition  change 
and  evolve  over  its  life-cycle,  the  roles  of  various  IPTs  and  IPT  members 
evolve.  When  the  team  is  dealing  with  an  area  that  requires  a  specific 
expertise,  [a  Subject  Matter  Expert  (SMEj),  the  role  of  the  member  with 
that  expertise  will  predominate;  however,  other  team  members’  input 
should  be  integrated  into  the  overall  life-cycle  design  of  the  product. 

Some  teams  may  assemble  to  address  a  specific  problem  and  then  become 
inactive  or  even  disband  after  accomplishing  their  tasks. 

The  IPTs  help  effectively  translate  user-defined  capabilities  into  operational 
system  specifications  that  are  consistent  with  cost,  schedule,  and  performance  constraints. 
IPTs  facilitate  meeting  cost  and  performance  objectives  from  product  concept 
development  through  production,  including  field  support  by  using  the  key  tenet  of 
multidisciplinary  teamwork.  Multidisciplinary  teamwork  allows  for  more  effective 
communication  between  stakeholders,  so  that  project  decisions  can  be  made  more 
efficiently  and  effectively  with  an  understanding  of  overall  system  impact.  IPTs  are 
crucial  in  the  SE  approach  because  they  allow  the  stakeholders  to  effectively 
communicate  and  resolve  issues  that  if  not  addressed  early  in  the  design  process  can  have 
a  negative  impact  on  the  cost,  schedule,  and  performance  of  the  system. 
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Figure  33  shows  a  generic  SE  model  with  a  view  of  the  ideal  level  of  effort 
(work)  and  duration  of  the  different  SE  process  phases.  Each  phase  is  explained,  along 
with  “ideal”  people  type  per  phase This  model  will  be  used  as  the  generic  model 
which  other  models  could  be  transposed  on  and  related. 

A,  “X”  PHASE— THE  IDEA 

The  acquisition  process  begins  with  a  need  by  a  customer,  “X”  in  Eigure  33.  “X” 
is  the  big  idea,  concept,  or  dream,  of  a  system  and  consists  of  a  generic  top-down  view. 

1,  “X”  Phase  People 

These  people  are  the  “big  picture”  thinkers,  visionaries,  and  dreamers.  “X” 
people  take  the  end-user  needs,  analyze  them,  and  are  capable  of  correctly  describing  the 
capability  gap — the  need — that  requires  a  materiel  solution.  Since  they  understand  the 
“big  picture,”  they  do  not  concern  themselves  with  the  intricate  details  of  the  systems 
they  require. 

B,  “A”  PHASE— CONCEPT  DESIGN 

The  big  picture  architecture,  top-down  view  of  the  system,  is  developed  in  the 
“A”  phase  of  this  SE  process.  The  system  developer  takes  the  customer’s  need  “X,”  and 
translates  them  into  a  concept  design  and  preliminary  architecture  design,  which  help 
define  stakeholder  requirements.  Correctly  eliciting  system  requirements  early  in  the 
process,  can  help  reduce  the  overall  cost,  determine  a  more  accurate  schedule,  and  ensure 
desired  performance  of  the  system.  Careful  coordination  is  required  among  the 
stakeholders  to  ensure  that  conceptual  design  tradeoffs  are  correctly  analyzed  and 
implemented,  and  that  defined  requirements  and  concepts  are  properly  documented.  In 
this  phase,  concept  design  and  agreement  of  the  acceptance  test  is  carried  out. 


This  SE  model  and  “ideal”  people  types  was  developed  by  Dr.  Lawrence  Goshom  in  the  1960s  as 
the  Chairman  of  General  Automation  Incorporated.  This  is  a  different  perspective  on  the  SE  model 
described  by  ISO/IEC  15288,  Blanchard  and  Fabrycky,  and  Buede  [72]  [73]. 
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(X)  -  The  Need  (the  Customer) 
A  -  Conceptual  Design 
B  -  Detailed  Design 

Test  &  Evaluation  Plans 


D  -  System  Integration  -  bring  all  together 
Debugging  /  System  Works 
Customer  signs  off  on  system 
E  -  Clean-up 


C  -  Implementation  Manuals  (System,  Training,  Manufacturing) 

Detailed  sub-system  &  component  design  Other  documentation 
Begin  Building  Other  ;  Production,  Operational  Use, 

Refinement,  Retirement,  Disposal 


Figure  33.  Overview  of  Systems  Engineering  Phases  with  Cost  and  Time  (From  [74]) 


1,  “A”  Phase  People 

“A”  people  interaet  eonstantly  with  the  eustomer,  “X”  types,  thus  “A”  people 
usually  have  marketing,  business,  and  detail  design  experienee^^  “A”  people  need  to  be 
able  to  effectively  communicate  with  the  customer  to  correctly  elicit  the  system 
requirements.  “A”  people  need  to  also  interact  with  “B”  people,  to  make  sure  what  they 
plan  is  technically  feasible,  and  therefore  “A”  people  with  technical  backgrounds 
(typically  were  a  “B”  person  previously)  are  more  successful. 


C.  “B”  PHASE— DETAILED  DESIGN 

The  “B”  phase  takes  big  picture  preliminary  system  design  architecture  and 
breaks  it  up  into  system,  sub-system,  component,  and  system  detailed  specifications  (e.g., 
turns  architectures  into  detailed  engineering,  physics,  terms,  specifications,  etc.).  The 
detailed  design  phase,  or  detailed  architecture  design  phase^*’,  uses  the  concept  design 


Design  experience  refers  to  technical  understanding  of  the  type  of  system  to  be  developed. 
80  Preliminary  architecture  is  done  in  the  “A”  phase. 
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from  “A”  phase  to  create  a  detailed  system  design.  Exact  specifications  for  the  system, 
its  sub-systems,  and  interfaces  emerge  and  the  bottom-up  engineering  details  are  created 
using  the  top-down  architecture  (from  “A”)  and  the  details  of  how  the  top-down  and 
bottom-up  designs  will  be  integrated.  Rapid  prototyping  is  done  in  this  phase. 

Test  and  evaluation  plans  are  created,  and  detailed  acceptance  tests  are  specified, 
in  order  to  show  the  stakeholders  that  the  “X”  phase  needs  are  met. 

1.  “B”  Phase  People 

“B”  phase  people  are  engineers  with  technical  experience  that  push  the 
technology  boundaries  with  a  “can  do”  attitude  that  is  at  times  overly  optimistic.  “B” 
people  interface  with  “A”  and  “C”;  therefore  they  need  to  technically  commit  to  “A”  and 
make  sure  the  plan  is  feasible  for  “C”  people  and  encourage  “C”  people  that  this  system 
is  doable  (show  them  the  system  vision). 

2.  “C”  Phase — Implementation 

This  phase  begins  implementation  of  the  system  design  as  detailed  sub-system 
designs  are  finalized  and  sub-systems  are  built.  The  majority  of  the  work  is  conducted 
during  this  phase  as  the  system(s)  are  built  at  a  certain  rate  over  time.  The  qualification 
system  for  the  acceptance  tests  is  further  designed  (from  the  detailed  acceptance  tests 
design  from  “B”)  and  implemented  in  this  phase.  At  the  end  of  “C,”  each  subsystem  and 
the  qualification  system  is  tested. 

a.  “C”  Phase  People 

“C”  phase  people  are  also  engineers.  They  are  experts  in  the  sub-system 
technical  areas.  The  best  “C”  phase  people  often  move  to  work  in  the  “B”  phase. 

3.  “D”  Phase — System  Integration 

System  integration  involves  the  integration  of  the  built  sub-system(s)  to  make  up 
the  whole  system.  During  integration,  debugging  of  the  system  is  conducted  on  the 
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designed  and  built  systems,  and  testing  is  aeeomplished  through  the  aceeptanee  test,  to 
show  that  the  designed  and  built  system  works,  and  that  it  meets  the  stakeholder’s 
requirements. 

The  people  from  the  “A,  B,  and  C”  phases  are  involved  in  the  debugging  of  the 
integrated  system  in  the  “D”  phase.  The  paee  of  this  phase  is  fast  and  hectie  beeause  of 
the  “unknown”  and  “known”  issues  that  develop  as  the  systems  are  integrated,  and  the 
timeline  for  product  delivery  gets  tight. 

The  integrated  system  is  demonstrated  to  the  stakeholders,  in  order  to  ensure  that 
the  requirements  of  the  “X”  phase  are  met.  There  will  be  rework  and  changes  to  the 
system  as  the  stakeholders  (customers  and  “A,  B,  and  C”  phase  personnel)  negotiate  the 
acceptance  criteria  for  the  final  production  system^!.  Stakeholder  requirements  are 
compared  to  the  capabilities  delivered  by  the  systems  during  Verification  and  Validation 
(V&V  or  acceptance  test),  and  negotiation  of  the  percentage  of  the  final  product  end-user 
requirements  that  are  met. 

A  perfect  SE  process  could  ensure  that  all  stakeholders  are  involved  in  design  and 
production  decisions,  and  that  the  capability  tradeoffs  are  acceptable,  and  understood,  by 
all  stakeholders.  The  integration  of  different  sub-systems  can  be  challenging  and  a  lot  of 
effort  will  be  spent  mitigating  integration  issues.  By  keeping  all  informed  of  the 
tradespace  decision  process,  the  risk  of  getting  to  the  “D”  phase  and  integrating  a  product 
that  is  not  acceptable  to  either  the  customer  or  other  stakeholders  is  greatly  reduced. 

a.  “D  ”  Phase  People 

The  “D”  phase  people  are  the  leaders  from  the  “A,  B,  and  C”  phases  that 
understand  the  sub-systems  and  how  they  will  interact  when  integrated  into  the  whole 
system.  They  are  determined  to  make  the  system  work,  and  will  work  night  and  day  to 
achieve  successful  systems. 


Acceptance  test  criteria  should  be  agreed  in  earlier  phases. 
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4.  “E”  Phase — Clean-up 

The  clean-up  phase  is  the  last  part  of  the  SE  process,  before  production,  where  the 
system  manuals  (training,  maintenance,  and  operation)  are  developed,  delivered,  and 
training  is  conducted  for  the  end-users. 

As  the  system  proceeds  past  the  delivery  phase,  production  of  the  item  continues 
(in  the  “F”  phase),  as  well  as  operational  use  (“G”  phase),  system  refinement,  upgrades 
(“H”  phase),  retirement  (“I”  phase),  and  disposal  (“J”  phase). 

a.  “E”  Phase  People 

“E”  phase  people  like  to  “clean-up”  the  system  design  by  documenting 
configurations,  developing  end-user  training  documents,  and  cleaning  up  design  issues. 
These  people  usually  are  writers  and  enjoy  developing  documentation,  for  example 
training  documents,  etc. 

5.  “Other”  Phases 

For  systems  that  have  multiple  units  that  are  delivered  to  the  customer,  there  is  the 
continued  production  of  the  system  (with  some  delivery  timeline). 

There  is  also  the  operational  use  of  the  product  (“G”)  as  well  as  the  maintenance 
(“H”)  and  repair  to  the  system.  In  addition,  there  is  system  refinement  (“H”),  as  planned 
and  unplanned,  but  necessary,  upgrades  are  incorporated  into  the  system  design. 

There  is  the  planning  for  system  retirement  (“I”)  and  disposal  (“J”)  used  once  the 
system  has  exceeded  its  useful  life. 

a.  “Other”  Phase  People  (“F,  ”  “G,  ”  “H,  ”  %  ”  “J”) 

These  people  are  mostly  life-cycle  support  personnel  who  carry  out 
production,  ensure  maintenance,  perform  upgrades,  provide  support,  and  who  will  plan 
for  retirement,  and  disposal  of  the  system. 

The  previous  two  sections  describe  the  different  SE  process  model.  The 
next  section  will  address  the  mapping  of  the  generic  SE  approach  to  the  DoD  Acquisition 
Process. 
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